[Bug c/19087] New: Overflowed address in dwarf debug line information

[Bug c/19087] New: Overflowed address in dwarf debug line information

[tsandnes at atmel dot com]

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

-- 
           Summary: Overflowed address in dwarf debug line information
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tsandnes at atmel dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mingw32
  GCC host triplet: 386
GCC target triplet: AVR


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug debug/19087] Overflowed address in dwarf debug line information

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 12:53 -------
Can you attach a preprocessed source?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |debug


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug debug/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot no]

------- Additional Comments From tsandnes at atmel dot no  2004-12-20 13:40 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug debug/19087] Overflowed address in dwarf debug line information

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 13:43 -------
Just the preprocessed for largeandsimple.c will be fine.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug debug/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot com]

------- Additional Comments From tsandnes at atmel dot com  2004-12-20 14:02 -------
Created an attachment (id=7782)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7782&action=view)
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[pinskia at gcc dot gnu dot org]

------- 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot no]

------- Additional Comments From tsandnes at atmel dot no  2004-12-20 14:15 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[ericw at evcohs dot com]

------- Additional Comments From ericw at evcohs dot com  2004-12-20 17:44 -------
(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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ericw at evcohs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[ericw at evcohs dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bjoern dot m dot haase at
                   |                            |web dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

------- Additional Comments From dwatkins at tascsystems dot com  2005-02-16 00:04 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

------- 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

[Bug target/19087] Overflowed address in dwarf debug line information

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-17 01:22 -------
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?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

------- Additional Comments From dwatkins at tascsystems dot com  2005-03-07 16:31 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

------- Additional Comments From dwatkins at tascsystems dot com  2005-03-07 22:50 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot no]

------- Additional Comments From tsandnes at atmel dot no  2005-03-08 07:07 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[tsandnes at atmel dot com]

------- Additional Comments From tsandnes at atmel dot com  2005-03-11 07:43 -------
> 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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[ericw at evcohs dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19885


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]


------- 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? 
 
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 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[tsandnes at norway dot atmel dot com]

------- Additional Comments From tsandnes at norway dot atmel dot com  2005-05-09 07:01 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]


------- Additional Comments From bjoern dot m dot haase at web dot de  2005-05-30 21:40 -------
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 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

------- Additional Comments From bjoern dot m dot haase at web dot de  2005-05-30 21:16 -------
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 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[giovannibajo at libero dot it]

-- 
Bug 19087 depends on bug 19885, which changed state.

Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

-- 

eweddington at cso dot atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[aesok at gcc dot gnu dot org]

------- Comment #31 from aesok at gcc dot gnu dot org  2007-02-15 20:13 -------
Fixed in 4.1.3, 4.2.0 and 4.3.0.


-- 

aesok at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[aesok at gcc dot gnu dot org]

------- Comment #30 from aesok at gcc dot gnu dot org  2007-02-15 20:02 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #29 from eweddington at cso dot atmel dot com  2007-02-13 19:00 -------
Can a bug master please close this bug as fixed?

Thanks
Eric Weddington


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[aesok at gcc dot gnu dot org]

------- Comment #28 from aesok at gcc dot gnu dot org  2007-01-31 17:35 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[aesok at gcc dot gnu dot org]

------- Comment #27 from aesok at gcc dot gnu dot org  2007-01-31 17:24 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #26 from eweddington at cso dot atmel dot com  2006-09-21 15:18 -------
(From update of attachment 12162)
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.


-- 

eweddington at cso dot atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12162|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #25 from eweddington at cso dot atmel dot com  2006-09-20 03:38 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[dberlin at gcc dot gnu dot org]

------- Comment #24 from dberlin at gcc dot gnu dot org  2006-09-20 00:00 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #23 from eweddington at cso dot atmel dot com  2006-09-19 21:54 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #22 from eweddington at cso dot atmel dot com  2006-08-31 15:41 -------
Created an attachment (id=12162)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12162&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #21 from eweddington at cso dot atmel dot com  2006-08-31 15:39 -------
Created an attachment (id=12161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12161&action=view)
Patch to select 32 bit DWARF addresses for the AVR target.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[j at uriah dot heep dot sax dot de]

------- Comment #20 from j at uriah dot heep dot sax dot de  2006-03-27 20:53 -------
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.


-- 

j at uriah dot heep dot sax dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |j at uriah dot heep dot sax
                   |                            |dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

------- Comment #19 from eweddington at cso dot atmel dot com  2005-12-28 23:01 -------
Bugmasters,
Is there any more information needed, or can this bug be marked as NEW?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087