PATCH: fix dwarf2 generation for PTR_SIZE = 2 & 8
Sat Mar 4 01:42:00 GMT 2000
Jason Merrill wrote:
> > - The padding of the address range header is not correct. No padding
> > is necessary for 16-bit pointers (because 12 = 3 * (2*PTR_SIZE)).
> > I suggest a more general form for the padding. It works for any
> > pointer size and any DWARF_OFFSET_SIZE. The new define
> > DWARF_ARANGES_PAD_SIZE tells how many bytes of padding we have.
> > I suggest to emit the padding as 2-byte quantities; this is more general
> > and we know it is a multiple of 2, at least.
> You should generalize the comment on the padding as well as the
> calculation; why is it calculated that way?
The mail explanation is not generalized to point out the problem.
The patch comment is generalized as well as the calculation:
/* Size of padding portion in the address range info. It must be
aligned to twice the pointer size. */
#define DWARF_ARANGES_PAD_SIZE \
(DWARF_ROUND (2 * DWARF_OFFSET_SIZE + 4, PTR_SIZE * 2) \
- (2 * DWARF_OFFSET_SIZE + 4))
/* We need to align to twice the pointer size here. */
What kind of more generalization could we have ?
This is calculated that way because it seemed to me it was much
more understandable: sizeof(dwarf-header) - sizeof(what was emitted).
> > - DWARF_ROUND only worked for power of 2 rounding.
> > I suggest a generalization
> No; we're only interested in powers of 2.
You cannot assume that. You can have architectures with PTR_SIZE == 3.
There are other problems but such configuration exist. The motorola
embedded working group has defined such DWARF-2 format for 68HC12
processors ( http://www.mcu.motsps.com/dev_tools/hc12/eabi/hc12eabi.pdf ).
The PTR_SIZE being a constant, the macro I propose has the same
efficiency as yours for powers of 2.
E-mail: email@example.com Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
More information about the Gcc-patches