The mapping between addresses and code locations is invalid in object files compiled for AVR targets that addresses code above 64K. This seems like a "rollover" bug because addresses immediately above 64K have values near 0. To reproduce this bug, generate a source file that uses more than 64K of program memory and try to parse the .debug_line section using libdwarf or by implementing the state machine described in section 6.2 of "DWARF Debugging Information Format" revision 2.0.0 This is probably a side-effect of the AVR usually only addressing 64K of program memory. http://reality.sgi.com/davea/ http://dwarf.freestandards.org/modules.php?name=Content&pa=showpage&pid=6
Can you attach a preprocessed source?
Subject: Re: Overflowed address in dwarf debug line information pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:53 ------- > Can you attach a preprocessed source? Hmm, That will probably be a problem. I have just piled together a lot of generated code and a library to be able to create an object with this much program memory. Would the preprocessed source (of the file with main()) be of use anyway? The library is a trick to fool avr-gcc into creating the object without failing. If I just put it all in one file and try to compile it I get errors like these: >avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 largeandsimple.c -o largeandsimple.elf c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccewaaaa.s: Assembler messages: c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccewaaaa.s:55075: Error: value of 66702 too large for field of 2 bytes at 16 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccewaaaa.s:92562: Error: value of 66702 too large for field of 2 bytes at 52828 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccewaaaa.s:54188: Error: value of 65542 too large for field of 2 bytes at 10009 ... Hmm, come to think of it, maybe I should report this as a bug too? Torleif
Just the preprocessed for largeandsimple.c will be fine.
Created attachment 7782 [details] Preprosessed source of a large object file that fails to build for atmega128 Trying to produce a simple and independent test case to reproduce this bug, I generated a lot of sourcecode and put it in one file. ( The goal was to get above 64K). When compiling this file, i get this output from avr-gcc: avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 -save-temps largeandsimple.c -o largeandsimple.elf c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUzaaaa.s: Assembler messages: c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUzaaaa.s:55075: Error: value of 66702 too large for field of 2 bytes at 16 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUzaaaa.s:92562: Error: value of 66702 too large for field of 2 bytes at 52836 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUzaaaa.s:54188: Error: value of 65542 too large for field of 2 bytes at 10009
Hmm, on the mainline I get an error about dwarf2 not being supported: t.c:1: error: target system does not support the "dwarf-2" debug format
Subject: Re: Overflowed address in dwarf debug line information pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 14:05 ------- > Hmm, on the mainline I get an error about dwarf2 not being supported: > t.c:1: error: target system does not support the "dwarf-2" debug format avr-gcc must be built with dwarf support to be able to produce objects with dwarf2 debugging information. It is probably nececssary to build the entire toolchain from scratch. Something like this. 1 cd binutils 2 ./configure --target=avr-elf --with-dwarf2 3 gmake 4 gmake install 5 cd ../gcc 6 ./configure --enable-languages=c,c++ --target=avr --with-dwarf2 7 gmake 8 gmake install 9 cd ../avr-libc 10 ./configure --prefix=/usr/local 11 gmake 12 gmake install Are you familiar with the AVR port? Thanks for looking into this! Torleif
(In reply to comment #5) > Hmm, on the mainline I get an error about dwarf2 not being supported: > t.c:1: error: target system does not support the "dwarf-2" debug format > If you're talking about HEAD/4.0, then a seperate bug report needs to be filed. The avr port needs to be able to be configured for DWARF2 debug info. (Yes, I know that the avr port of GDB only uses stabs, but other tools use DWARF2.) The OP is using 3.4.1.
Regarding this bug and AVRFreaks Forum topic: http://www.avrfreaks.com/index.php? name=PNphpBB2&file=viewtopic&t=23436&highlight=&sid=e1dbd9f208947a5efc679075b4af f237 in which the debug info for code past the first 64k of program space wraps, overlaying the information at the lower 64k, I may have identified the problem. It appears that using POINTER_SIZE = 16 results in DWARF2_ADDR_SIZE being derived as 2 when it should be 4. This would normally not be an issue except that in code generation the pointers appear to address 64k words (128k bytes), but for debug info the address fields appears to address program space in bytes, thus wrapping for the second 64k when the address field size is 16 bits. I rebuilt GCC with the following change added to gcc/config/avr/avr.h just after the define for POINTER_SIZE... #define DWARF2_ADDR_SIZE 4 GCC rebuilt, and my AVR libraries and project all rebuilt, but at this point, when attempting to load it into AVRStudio4.11, it results in a rather dramtic looking Visual C++ runtime error from AVRStudio.exe. I obviously don't have a fix, but perhaps someone more familiar will recognize what I attempted to do and know what further needs to be done to both resolve the problem and retain interoperability with AS4. Regards, Darcy
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
Not sure if it's helpful (or further complicating) but as the avr uses a Harvard memory model; it's PC (program counter) actually references a 64K 16-bit program word address space which is orthogonal to it's 64KB data memory space (although a few specialized instructions do allow restrictive reference to it's program address space). So wonder if program address should actually more simply be pre-scaled as being a word address, not byte address, thereby only requiring 16-bit (2 byte) program references by compiler/sssembler/etc.; thereby possibly sidestepping the otherwise necessity for a wider type to store program debug references (so coincidently wonder if this problem should also be simultaneously reported against binutils/gas/ld avr tools; which reminds me that I recall a few patches being checked in to cvs for gas/HEAD which extended it to support 16-bit (up from 15-bit) displacements, which may be a step along the path to a solution of the problems observed?)
Hello, I have an update. Torlief sent me a beta set of AS4 parser DLLs built to work ONLY with 32 bit address sizes in dwarf information. I tried it out and noticed the following differences. 1. Single stepping through my program now appears to work much better. I no longer observe jumping back and forth between two source files as before. 2. Disassembler view shows the source for the code above 0x00008000 (word address) in the proper locations with code above 0x00008000. I also noticed the following side effects which don't directly bear on the subject of this bug, but may be related to the same root causes. 1. On my development PC using latest WinAVR distribution and AS4.11 with the distribution parser DLLs, in one source module, I can hover over a global variable and see the address and value. On my quarantined environment I use to experiment / debug the tool suite, I observe "invalid location" when I hover over the same variables. 2. On my development PC, in the same source module, when I hover over a local (automatic) variable, no "hover-over" popup information is displayed. On my quarantined environment, when I hover over the same variables, I see data values. I must mention something about my quarantined environment. I built it just before the latest WinAVR release so I think I want to make sure that it is in sync with all the same patches used for the latest WinAVR before concluding my test here, ... but so far the results appear very promising.
Hello, I applied the GCC and binutil patches to ensure that my gcc is the same as that used in WinAVR Feb14/05 distribution. I then built libc1.2.3 and clean built my project. Loaded it all into AS4.11 with the beta parser DLLs. No difference. With the 32 bit dwarf address, line number info seems ok, local automatic variables seem ok but the static and global variables all appear as invalid locations when hovering over them. I'll wait for any comments from Torleif as to whether this is at the AS4 parsing end or during one of the earlier stages (i.e. in GCC or binutils). Regards, Darcy
Subject: Re: Overflowed address in dwarf debug line information > I applied the GCC and binutil patches to ensure that my gcc is the same as that > used in WinAVR Feb14/05 distribution. I then built libc1.2.3 and clean built > my project. Loaded it all into AS4.11 with the beta parser DLLs. No > difference. > > With the 32 bit dwarf address, line number info seems ok, local automatic > variables seem ok but the static and global variables all appear as invalid > locations when hovering over them. > > I'll wait for any comments from Torleif as to whether this is at the AS4 > parsing end or during one of the earlier stages (i.e. in GCC or binutils). Great work! If you could send me the object file , I could debug my 32-bit parser version to check out this problem with global/static data. It is hard to make any statement on whether this is a parser or avr-gcc deficiency before investigating the object file. Regards, Torleif
> Here is the ELF file. Runs on an ATmega128 using about 75% code space, > almost all of 32k expanded SRAM and almost all of EEPROM. I hope that this > helps. Please treat the file as confidential. > > BTW, I sent this from home because I didn't have the laptop with me at work > today and figured this would help with the time zone differences, etc. > Please make sure that any reply makes it to my work email in the CC. I have had a quick look at the objectfile with avr-readelf -w and found that global and static variables are in locations that are way beyond the atmega128's 4K of flash memory. It seems that flash addresses in the debuginformation are no longer subtracted by 0x800000. (The flash offset used by avr-gcc) For example, the last_baud_rate variable quite early in the objectfile is stated to be at address 0x80019c: <2><851>: Abbrev Number: 21 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x188): last_baud_rate DW_AT_decl_file : 22 DW_AT_decl_line : 710 DW_AT_type : <2c> DW_AT_location : 5 byte block: 3 9c 1 80 0 (DW_OP_addr: 80019c) Probably, 0x19c is the correct address. If you can fix this, I think we are done. (except maybe for similar problems with the eeprom segment) Regards, Torleif
Hi Torleif, I have just had a look at PR19885 and I am having one additional question: IIUC, the lable references, that eventually cause the overflow problems refer to memory in form of "byte" addresses and not "word" addresses: I.e. the offsets and address information you are finding in the elf files all are "byte" addresses. Am I right? In the asm outputs I have investigated so far, I realized that for the lable references in the dwarf sections avr-gcc is allocating two bytes only. So in case that these two bytes are filled with "byte" addresses instead of "word" addresses, it is obvious that an overflow could not be avoided. The cleanest solution then would be to redefine the debugging format such that within the debugging sections for the dwarf symbols, gcc allocates four bytes for the pointers. I fear, however, that this would be a major challenge since one would probably need to rewrite a considerable portion of the dwarf-output-genenerator in a target-specific fashion. If I'm not too wrong, we probably won't have a short term solution for this PR. Anyway, I think that this bug should be marked as NEW. Yours, Björn
Subject: Re: Overflowed address in dwarf debug line information bjoern dot m dot haase at web dot de wrote: > ------- Additional Comments From bjoern dot m dot haase at web dot de 2005-05-06 14:12 ------- > Hi Torleif, > > I have just had a look at PR19885 and I am having one additional question: > IIUC, the lable references, that eventually cause the overflow problems refer > to memory in form of "byte" addresses and not "word" addresses: I.e. the > offsets and address information you are finding in the elf files all are "byte" > addresses. Am I right? Yes. This is what I have observed. avr-readelf with the -w switch is very useful for viewing the debug information. > In the asm outputs I have investigated so far, I realized that for the lable > references in the dwarf sections avr-gcc is allocating two bytes only. So in > case that these two bytes are filled with "byte" addresses instead of "word" > addresses, it is obvious that an overflow could not be avoided. The cleanest > solution then would be to redefine the debugging format such that within the > debugging sections for the dwarf symbols, gcc allocates four bytes for the > pointers. I fear, however, that this would be a major challenge since one would > probably need to rewrite a considerable portion of the dwarf-output-genenerator > in a target-specific fashion. > If I'm not too wrong, we probably won't have a short term solution for this PR. I think your explanation makes sense. But how can target specific code be added to the dwarf output generator? AFAIK everything AVR related must be put in the avr.c, avr.h or avr.md in the gcc/config directory. Must it not rather be rewritten to work for all targets *and* the AVR port? Thanks for taking the time to look into this. Torleif
Hi, as a step towards resolving PR19885: After looking a bit into the code of other ports, I found out, that switching avr-gcc to the 4-byte dwarf convention should not be complicated at all. It seems that the only thing to be done is add the lines #undef DWARF2_ADDR_SIZE #define DWARF2_ADDR_SIZE 4 to avr.h . This is how it works for HC12, ip2k and other ports that override the default definition of 2 for these targets. For AVR, most probably, one should then expect the occurence of trailing 0x80 bytes indicating the memory space. Torleif has already prepared a new parser dll for avrstudio that is supposed to run with 4-Byte dwarf debugging info. Quote (Torleif Sandes): "My dwarf parser is composed of several dlls. The one governing low-level dwarf access (such as the size of pointers), is called libdwarf.dll and is a windows port of an LGPL licensed library. I have built this library with the required change and put it at http://www.atmel.no/beta_ware/as4/elfdwarfparser/libdwarf.dll" I will unfortunately not have time to look into details during the next two weeks. So in case that someone else volunteers (best would be someone who has access to a atmega128 board). Before implementing such a change, in case that it passes tests of course, one should probably carefully think about how to manage the transition: There is possibly quite a couple of object code out there that still has 2-Byte dwarf information included. I am mainly thinking about the WOE users working with avrstudio and Eric's precompiled winavr toolchain. Maybe one should do implement a simultaneous change of type "For avrstudio 3.4.1 always use winavr 6.2.8 or later." Possibly one should consider to implement the 2-Byte -> 4-Byte switching at the next 4.0 revision.? Yours, Bjoern
OK, sorry for this, but I just realized that Darcy Watkins has made a couple of almost exactly identical observations. Did not review all of the more recent comments. In case that the only remaining problem turns out to be the trailing 0x80 that indicate the memory space, one way to handle it could be to change the way the asm output is generated. I.e. there is a quite easy method for forcing gcc to generate .long ((lable_referenced_within_the_dwarf_section) & 0x0001FFFF) instead of .long lable_referenced_within_the_dwarf_section . This way, when assemling one could mask out leading bits that possibly could irritate avrstudio. However, IMO, the better way would be to teach avrstudio simply to ignore the bits that are known to be not relevant. Yours, Björn
Bugmasters, Is there any more information needed, or can this bug be marked as NEW?
I suggest that this change should be accompanied by another indication in the output that tells the ELF/DWARF-2 consumer about the changed pointer size. Otherwise the consumer will experience "funny" behaviour. While there are many ELF fields available that are otherwise unused on this architecture (like the OS or ABI fields), there doesn't seem to exist any practical way to modify their contents through the assembler/linker interface. Thus, and after checking other GCC code like the section ".note.GNU-stack" suggested at the end of varasm.c, I think adding something like named_section_flags (".note.DWARF2-32", SECTION_DEBUG); to function avr_file_end() in gcc/config/avr/avr.c appears to be a suitable way to me to flag this information to the potential consumer.
Created attachment 12161 [details] Patch to select 32 bit DWARF addresses for the AVR target.
Created attachment 12162 [details] Patch to add a note to the ELF file to notify the difference between old ELF files and new ELF files with different DWARF address sizes.
(In reply to comment #20) > I suggest that this change should be accompanied by another indication in > the output that tells the ELF/DWARF-2 consumer about the changed pointer > size. Otherwise the consumer will experience "funny" behaviour. > > While there are many ELF fields available that are otherwise unused on > this architecture (like the OS or ABI fields), there doesn't seem to exist > any practical way to modify their contents through the assembler/linker > interface. Thus, and after checking other GCC code like the section > ".note.GNU-stack" suggested at the end of varasm.c, I think adding something > like > > named_section_flags (".note.DWARF2-32", SECTION_DEBUG); > > to function avr_file_end() in gcc/config/avr/avr.c appears to be a suitable > way to me to flag this information to the potential consumer. Joerg, I've been trying this, but something strange is going on. On the linker command line, I specify for it to create a map file. I can correctly see the new section, .note.DWARF2-32, in the map file. However, when I use avr-objdump on the resulting ELF file, the section looks like it is not there. So can the linker show the section when it generates the map file, but then remove the section, because the section is empty, when it does the final generation of the ELF file? Thanks Eric
You guys should be aware that dwarf2/3 has a field in the header of each dwarf compilation unit labeled "address size" that tells what the address size for that compilation unit is. If this is set to 4, you should be able to use 4 byte addresses and any conforming dwarf2 reader will understand it and use it to determine how many bytes the address forms (DW_FORM_addr, etc) use. See section 7.5.1 of the DWARF3 standard. This is the way the consumer is supposed to know what the address size in a dwarf2 is (there is also a way to tell the consumer what the offset size should be for file offsets, in case you want to have really large debug info on a machine with < 8 byte *addresses*), i'm not sure why you think you need an extra note. See the rest of the DWARF2/3 specification for more details.
(In reply to comment #24) > i'm not sure why you think you need an > extra note. Because we weren't aware of the information that you thoughtfully laid out and put in this bug report? :-) Thank you very much for doing this! > See the rest of the DWARF2/3 specification for more details. Torleif can you take a look at this new info and see if it will work for you? Thanks Eric Weddington
Comment on attachment 12162 [details] Patch to add a note to the ELF file to notify the difference between old ELF files and new ELF files with different DWARF address sizes. The gcc-4.1.1-dwarf32-note.patch file is obsolete and no longer needed. Torleif was able to build a parser to work with both size DWARF addresses.
Subject: Bug 19087 Author: aesok Date: Wed Jan 31 17:23:49 2007 New Revision: 121426 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121426 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.h
Subject: Bug 19087 Author: aesok Date: Wed Jan 31 17:35:01 2007 New Revision: 121428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121428 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.h
Can a bug master please close this bug as fixed? Thanks Eric Weddington
Subject: Bug 19087 Author: aesok Date: Thu Feb 15 20:01:59 2007 New Revision: 122013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122013 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.h
Fixed in 4.1.3, 4.2.0 and 4.3.0.