------- Additional Comments From dwatkins at tascsystems dot com 2005-02-16
23:36 -------
Hello,
I have a few more notes to add.
1. The binary image of the project built as described in my last post here
runs properly on the target system.
2. On my main development PC (one release ago of WinAVR) I ran:
avr-objdump -S -l spl.elf >> dump.txt
And then examined the huge file that resulted. What I observed is that the >
64k located source was at the front (i.e. consistent with what I observed in
AVRStudio). I didn't observe any < 64k located source until after the end of
the "overlay" of the > 64k located source. Beyond 64k, there was no source
however function addresses still appeared ok.
3. On my gcc toolset PC, (cygwin and gcc toolset compiled from source) I ran:
avr-objdump -S -l spl.elf >> dump.txt
And then examined the huge file that resulted. The > 64k located line number
info is all above 64k, the < 64k line number info is all below 64k.
4. Torleif from Atmel emailed me acknowledging that AVRStudio expects the
Dwarf addresses to be 16 bits and that this is likely the cause of
the "allergic" reaction when I attempted to load up the file with 32 bit
addresses into AVRStudio.
I think we are not far away from having a solution but it appears that it will
require:
- AVR GCC emit dwarf debug info using 32bit address size
- AVRStudio be capable of parsing dwarf debug info using 32bit address size
It will be necessary to come up with a scheme to ensure that someone doesn't
attempt to interoperate incompatible versions of tools or link a mixture of
object files, some with 16 bit addresses and some with 32 bit addresses.
Darcy
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |dwatkins at tascsystems dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
