This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: fix dwarf2 generation for PTR_SIZE = 2 & 8
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: PATCH: fix dwarf2 generation for PTR_SIZE = 2 & 8
- From: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Date: Sat, 04 Mar 2000 10:43:17 +0100
- CC: gcc-patches at gcc dot gnu dot org
- References: <38B5960F.A88E5B87@worldnet.fr> <u9g0uimfwu.fsf@yorick.cygnus.com>
Hi Jason,
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.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr 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
France