This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR: 19885 [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
- From: Björn Haase <bjoern dot m dot haase at web dot de>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org,tsandnes at norway dot atmel dot com
- Date: Tue, 17 May 2005 08:08:33 +0200
- Subject: Re: [PATCH] PR: 19885 [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
- References: <email@example.com> <firstname.lastname@example.org> <20050516221216.GA31156@redhat.com>
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.
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:
"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 http://gcc.gnu.org/ml/gcc/2004-05/msg00186.html)