This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add a dwarf unit type to represent 24 bit values.
- From: Jason Merrill <jason at redhat dot com>
- To: John Darrington <john at darrington dot wattle dot id dot au>
- Cc: gcc-patches at sourceware dot org
- Date: Thu, 13 Sep 2018 13:33:34 -0400
- Subject: Re: [PATCH] Add a dwarf unit type to represent 24 bit values.
- References: <20180827192040.16550-1-john@darrington.wattle.id.au> <20180827192040.16550-2-john@darrington.wattle.id.au> <CADzB+2=7wbiWQi9rCLu2KnaUiGZd1vYKE3q8m7Z2GBi14XV9rQ@mail.gmail.com> <20180910144248.puqiz5icxktn4o4n@jocasta.intra> <CADzB+2k8V89O9-CT_ESMhBOq42g-2LuNN69bEQt1MgePzYsLPQ@mail.gmail.com> <20180913053501.2wgtveltqxhq4bd4@jocasta.intra>
On Thu, Sep 13, 2018 at 1:35 AM, John Darrington
<john@darrington.wattle.id.au> wrote:
> On Mon, Sep 10, 2018 at 04:40:58PM +0100, Jason Merrill wrote:
> On Mon, Sep 10, 2018 at 3:42 PM, John Darrington
> <john@darrington.wattle.id.au> wrote:
> > On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote:
> > On Mon, Aug 27, 2018 at 8:20 PM, John Darrington
> > <john@darrington.wattle.id.au> wrote:
> > > * include/dwarf2.h (enum dwarf_unit_type) [DE_EH_PE_udata3]: New member.
> >
> >
> > What's the rationale? Do you have a separate patch that uses this new macro?
> >
> > Yes. I there is an upcoming patch for GDB. See
> > https://sourceware.org/ml/gdb-patches/2018-08/msg00731.html
>
> This looks like support for reading fixed 3-byte values from the
> exception handling unwind information. Do you expect this information
> to ever need to store 3-byte values?
>
> Yes, I've already come across that (which is why I created the patch).
> Without this patch, GDB will barf. See the attached backtrace.
Well, that's curious, given that GCC doesn't have that address type either.
Ah, looking closer, I see that we aren't dealing with the EH unwind
information, but rather the normal DWARF unwind information, which
uses
/* The encoding for FDE's in a normal .debug_frame section
depends on the target address size. */
cie->encoding = DW_EH_PE_absptr;
it seems strange that GDB then wants to use one of the other codes as
a proxy for loading a particular number of bytes.
I also notice that the default definition of DWARF2_ADDR_SIZE in GCC
has a comment,
/* The size of addresses as they appear in the Dwarf 2 data.
Some architectures use word addresses to refer to code locations,
but Dwarf 2 info always uses byte addresses. On such machines,
Dwarf 2 addresses need to be larger than the architecture's
pointers. */
#define DWARF2_ADDR_SIZE ((POINTER_SIZE + BITS_PER_UNIT - 1) / BITS_PER_UNIT)
And many targets with smaller pointers override this in GCC and GAS, e.g.
./gas/config/tc-msp430.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-s12z.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-wasm32.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-xgate.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-aarch64.c:/* Implement DWARF2_ADDR_SIZE. */
./gas/config/tc-csky.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-avr.h:#define DWARF2_ADDR_SIZE(bfd) 4
Is this appropriate for your target, as well?
Perhaps GCC should double check that DWARF2_ADDR_SIZE is 2, 4, or 8.
Jason