User account creation filtered due to spam.

Bug 19087 - Overflowed address in dwarf debug line information
Summary: Overflowed address in dwarf debug line information
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.1
: P2 normal
Target Milestone: 4.1.3
Assignee: Not yet assigned to anyone
URL:
Keywords: assemble-failure
Depends on: 19885
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-20 09:54 UTC by Torleif Sandnes
Modified: 2007-04-09 22:16 UTC (History)
5 users (show)

See Also:
Host: 386
Target: AVR
Build: mingw32
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Preprosessed source of a large object file that fails to build for atmega128 (4.74 KB, text/plain)
2004-12-20 14:02 UTC, Torleif Sandnes
Details
Patch to select 32 bit DWARF addresses for the AVR target. (228 bytes, patch)
2006-08-31 15:39 UTC, Eric Weddington
Details | Diff
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. (270 bytes, patch)
2006-08-31 15:41 UTC, Eric Weddington
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torleif Sandnes 2004-12-20 09:54:10 UTC
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
Comment 1 Andrew Pinski 2004-12-20 12:53:49 UTC
Can you attach a preprocessed source?
Comment 2 tsandnes@atmel.no 2004-12-20 13:40:30 UTC
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
Comment 3 Andrew Pinski 2004-12-20 13:43:54 UTC
Just the preprocessed for largeandsimple.c will be fine.
Comment 4 Torleif Sandnes 2004-12-20 14:02:02 UTC
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
Comment 5 Andrew Pinski 2004-12-20 14:05:41 UTC
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
Comment 6 tsandnes@atmel.no 2004-12-20 14:15:44 UTC
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
Comment 7 Eric Weddington 2004-12-20 17:44:26 UTC
(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.
Comment 8 Darcy L. Watkins 2005-02-16 00:04:00 UTC
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
Comment 9 Darcy L. Watkins 2005-02-16 23:36:23 UTC
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
Comment 10 Paul Schlie 2005-02-17 01:22:23 UTC
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?)
Comment 11 Darcy L. Watkins 2005-03-07 16:31:24 UTC
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.
Comment 12 Darcy L. Watkins 2005-03-07 22:50:26 UTC
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
Comment 13 tsandnes@atmel.no 2005-03-08 07:07:42 UTC
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
Comment 14 Torleif Sandnes 2005-03-11 07:43:14 UTC
> 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
Comment 15 Björn Haase 2005-05-06 14:12:01 UTC
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 
Comment 16 tsandnes@norway.atmel.com 2005-05-09 07:01:53 UTC
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

Comment 17 Björn Haase 2005-05-30 21:16:25 UTC
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 
 
Comment 18 Björn Haase 2005-05-30 21:40:06 UTC
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 
Comment 19 Eric Weddington 2005-12-28 23:01:16 UTC
Bugmasters,
Is there any more information needed, or can this bug be marked as NEW?
Comment 20 Joerg Wunsch 2006-03-27 20:53:23 UTC
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.
Comment 21 Eric Weddington 2006-08-31 15:39:59 UTC
Created attachment 12161 [details]
Patch to select 32 bit DWARF addresses for the AVR target.
Comment 22 Eric Weddington 2006-08-31 15:41:05 UTC
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.
Comment 23 Eric Weddington 2006-09-19 21:54:42 UTC
(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

Comment 24 Daniel Berlin 2006-09-20 00:00:24 UTC
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.
Comment 25 Eric Weddington 2006-09-20 03:38:02 UTC
(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 26 Eric Weddington 2006-09-21 15:18:39 UTC
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.
Comment 27 aesok 2007-01-31 17:24:15 UTC
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

Comment 28 aesok 2007-01-31 17:35:18 UTC
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

Comment 29 Eric Weddington 2007-02-13 19:00:14 UTC
Can a bug master please close this bug as fixed?

Thanks
Eric Weddington
Comment 30 aesok 2007-02-15 20:02:19 UTC
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

Comment 31 aesok 2007-02-15 20:13:52 UTC
Fixed in 4.1.3, 4.2.0 and 4.3.0.