This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR: 19885 [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1

Am Dienstag, 17. Mai 2005 00:12 schrieb Richard Henderson:
> On Mon, May 16, 2005 at 10:41:44PM +0200, Björn Haase wrote:
> > Main issue seemingly was that the general dwarf2 code of gcc was not
> > ready to deal with HImode pointers.
> Can you say more about the problem?  I'd much rather fix any generic
> bug than work around the problem in the backend.
> r~
The problem showed up in dwarf2asm.c:109 when the RTX for calculating the 
difference of two lable references was wrong. What came out were expressions 
with illegal mixtures of modes (IIRC sub:HI with two SI operands). The 
background seems to be that AVR uses SI-Mode pointers for storing in the MSB 
which type of memory should be allocated and the pointers are truncated to HI 
mode only by the assembler/linker. I.e. the toolchain operates with 4-Byte 
pointers while the target code always operates with HImode pointers. My 
present explanation is that for this reason the use of calculations with 
Pmode for pointers in dwarf2asm.c seems not to be safe.

I did not study the problem much more in detail when realizing that the target 
could define macros for avoiding the expressions. If you consider it helpful, 
I could provide a more detailed failure report, e.g. post the generated rtx 
that causes the bootstrap failure when using --with-dwarf2.

Actually, in my opinion the best solution for the entire issue would be, to 
change the dwarf2 format convention so, that the debugging information always 
makes use of 4-Byte pointers. For this purpose, probably the debugger (gdb, 
avrstudio) parsers and gcc would need to be changed simultaneously. 
Background, why I consider 4-Byte pointers to be useful is PR19885. Since the 
avr targets could have more than 64k bytes of program memory, it would be 
helpful if the debugging information would not to be limited to the lower 



Concerning general issues within the mid-end concerning dwarf-2 generation: 
There seems to be another target-independent issue that is causing PR17993:

Jim Wilson:
"The DWARF2 info comes from dwarf2out.c. Grepping for 
DW_AT_data_member_location shows that it comes from the function 
add_data_member_location_attribute. The offset comes from the function 
field_byte_offset. Looking at this code, it seems to have a general problem 
on targets where TYPE_ALIGN of int is smaller than TYPE_SIZE of int. This is 
true on avr where the size is 2 but the alignment is 1. The code computes the 
end of the bitfield, subtracts the type size, and then rounds up to the 
alignment, which gives -1 for the offset, which is not a useful number. I 
would think the code would work better if we started with the beginning of 
the bitfield, and then rounded down to the alignment. I'd suggest checking 
the history of the code to see if there is a reason why it was written this 
way. There may be an obscure reason why the code is like it is"
(taken from

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]