DWARF-2 and address sizes

DWARF-2 and address sizes

[Daniel Jacobowitz]

[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?  Do we have to
worry about a binary in which different compilation units (or different
shared objects, even) have a different value for this?

If the consensus is "no, that's too stupid to be allowed to live", then this
gets much easier.

(Then consider DW_OP_deref_size; this is a fun one, since it has to be
zero-extended to the size of an address on the target machine according to
the spec, and then in GDB it may have to be zero or sign extended to the
size of a CORE_ADDR for storage.  I haven't tested any of this on MIPS yet
and I don't want to, damn it.  I don't know of any MIPS ABI with multiple
pointer sizes, and you can't link different ABIs, so encountering
DW_OP_deref_size is probably impossible.  I hope.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DWARF-2 and address sizes

[Andrew Cagney]

> [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.

But I don't think you'll encounter a case where cu_header->addr_size 
isn't locally consistent with the rest of the file.

>  Do we have to
> worry about a binary in which different compilation units (or different
> shared objects, even) have a different value for this?

See if binutils allows it.  If not ...

> If the consensus is "no, that's too stupid to be allowed to live", then this
> gets much easier.
> 
> (Then consider DW_OP_deref_size; this is a fun one, since it has to be
> zero-extended to the size of an address on the target machine according to
> the spec, and then in GDB it may have to be zero or sign extended to the
> size of a CORE_ADDR for storage.  I haven't tested any of this on MIPS yet
> and I don't want to, damn it.  I don't know of any MIPS ABI with multiple
> pointer sizes, and you can't link different ABIs, so encountering
> DW_OP_deref_size is probably impossible.  I hope.)

Have a look at dwarf2read.c:read_address() the existing code already 
handles one case of this.

Andrew

Re: DWARF-2 and address sizes

[Daniel Jacobowitz]

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 wonder if MIPS64 Linux kernels do this, since they're technically
ELF32?  Hmm, probably not.

GCC defines the address size as a constant (4) on ip2k and stormy16,
and in terms of pointer size elsewhere.  I don't know any platform
where objects with different pointer sizes can be linked together, and
it seems dubiously useful at best.

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.

> But I don't think you'll encounter a case where cu_header->addr_size 
> isn't locally consistent with the rest of the file.
> 
> > Do we have to
> >worry about a binary in which different compilation units (or different
> >shared objects, even) have a different value for this?
> 
> See if binutils allows it.  If not ...

Binutils, sadly, doesn't care.  It only uses the address size within a
compilation unit.

> 
> >If the consensus is "no, that's too stupid to be allowed to live", then 
> >this
> >gets much easier.
> >
> >(Then consider DW_OP_deref_size; this is a fun one, since it has to be
> >zero-extended to the size of an address on the target machine according to
> >the spec, and then in GDB it may have to be zero or sign extended to the
> >size of a CORE_ADDR for storage.  I haven't tested any of this on MIPS yet
> >and I don't want to, damn it.  I don't know of any MIPS ABI with multiple
> >pointer sizes, and you can't link different ABIs, so encountering
> >DW_OP_deref_size is probably impossible.  I hope.)
> 
> Have a look at dwarf2read.c:read_address() the existing code already 
> handles one case of this.

Yes.  I don't know if it sign extends properly in all cases - I guess
it does if signed_address_p always matches whether a CORE_ADDR is a
signed type, but that's dubious.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DWARF-2 and address sizes

[Daniel Berlin]

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.

Re: DWARF-2 and address sizes

[Andrew Cagney]

> 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 wonder if MIPS64 Linux kernels do this, since they're technically
> ELF32?  Hmm, probably not.

Well, for ages elf32 was being used in MIPS64 with a 64 bit pointer.

>> >If the consensus is "no, that's too stupid to be allowed to live", then 
>> >this
>> >gets much easier.
>> >
>> >(Then consider DW_OP_deref_size; this is a fun one, since it has to be
>> >zero-extended to the size of an address on the target machine according to
>> >the spec, and then in GDB it may have to be zero or sign extended to the
>> >size of a CORE_ADDR for storage.  I haven't tested any of this on MIPS yet
>> >and I don't want to, damn it.  I don't know of any MIPS ABI with multiple
>> >pointer sizes, and you can't link different ABIs, so encountering
>> >DW_OP_deref_size is probably impossible.  I hope.)
> 
>> 
>> Have a look at dwarf2read.c:read_address() the existing code already 
>> handles one case of this.
> 
> 
> Yes.  I don't know if it sign extends properly in all cases - I guess
> it does if signed_address_p always matches whether a CORE_ADDR is a
> signed type, but that's dubious.

It sign extends sufficiently properly/often for it to at least appear to 
work.  Vis MIPS with 64 bit CORE_ADDR and registers but elf32.

Andrew

Re: DWARF-2 and address sizes

[Daniel Jacobowitz]

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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DWARF-2 and address sizes

[Jim Blandy]

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?