This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: DWARF-2 and address sizes
- From: Jim Blandy <jimb at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Andrew Cagney <ac131313 at redhat dot com>, gdb at sources dot redhat dot com, Kevin Buettner <kevinb at redhat dot com>
- Date: 03 Feb 2003 21:16:11 -0500
- Subject: Re: DWARF-2 and address sizes
- References: <20030131223639.GA3585@nevyn.them.org><3B43101B-35AD-11D7-AA6D-000393575BCC@dberlin.org><20030201170152.GA29662@nevyn.them.org>
Daniel Jacobowitz <drow@mvista.com> writes:
> On Sat, Feb 01, 2003 at 01:20:17AM -0500, Daniel Berlin wrote:
> >
> > On Friday, January 31, 2003, at 05:36 PM, Daniel Jacobowitz wrote:
> >
> > >On Fri, Jan 31, 2003 at 04:59:56PM -0500, Andrew Cagney wrote:
> > >>>[Kevin, I noticed you doing some work in this area re S/390, maybe
> > >>>you've
> > >>>got a comment? Anyone else? I'm grasping at straws.]
> > >>>
> > >>>I'm trying to figure out how to handle addresses in the DWARF
> > >>>expression
> > >>>evaluator. First consider DW_OP_deref: the following data is "the
> > >>>size of
> > >>>an address on the target machine", which I would personally take to
> > >>>mean
> > >>>cu_header->addr_size. Is this ever different from
> > >>>TARGET_ADDRESS_BIT /
> > >>>TARGET_CHAR_BIT, which is what Daniel was originally using?
> > >>
> > >>I can imagine architectures wack-o enough for cu_header->addr_size !=
> > >>TARGET_ADDRESS_BIT / TARGET_CHAR_BIT. Someone doing a 16 bit port
> > >>using
> > >>32 bit elf.
> > ...
> >
> > >I'm willing to document this as an assertion, store the dwarf2 address
> > >size and signedness somewhere global, and bail if I detect a violation.
> > >But I'll skip that for now; it can be a later cleanup. I've already
> > >got too many pieces in this patch.
> > >
> >
> > IIRC, I did it some *other* way, and Jim told me to do it with the way
> > there now.
> > Or is that the other way around (He told me to do it some other way,
> > rather than what's there now, and i never got to it).
> > I believe I used to use one of the length of one of builtin types, and
> > he told me to use TARGET_ADDRESS_BIT / TARGET_CHAR_BIT.
> > The archives should say.
>
> Hmm, I didn't see it in the archives, so maybe I need to look further
> back. I'll check again.
>
> Jim, I don't suppose you remember?
I'm pretty sure that I saw the code simply using the whole CORE_ADDR
to do the dereferencing, and that I said it should be changed to use
the target's address size, since, in a gdbarch world, CORE_ADDR could
be larger than a target address. I don't think I specified whether
one should use cu->addr_size or TARGET_ADDRESS_BIT / TARGET_CHAR_BIT;
I doubt it occurred to me that they might be different.
Given the way cu_header->addr_size is used in the definition of
DW_FORM_addr (section 7.5.4, "Attribute Encodings"), I would expect it
to match the size of a linker symbol value --- since the point is to
provide something that can be relocated. But every ABI provides
relocs for smaller values, too, so it could be different.
I guess I don't really understand why this is a big deal. The baton
for the expression should record the addr_size and signed_addr_p from
the compilation unit it came from. Just use that many bits of
CORE_ADDR, sign-extended as directed. If this isn't right, we'll find
out eventually. We don't have any authority here to work from, so
that's the best we can do.
Or am I being too sloppy?