This is the mail archive of the
mailing list for the GDB project.
Re: DWARF-2 and address sizes
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com, Jim Blandy <jimb at redhat dot com>,Kevin Buettner <kevinb at redhat dot com>
- Date: Sat, 01 Feb 2003 02:28:51 -0500
- Subject: Re: DWARF-2 and address sizes
- References: <20030131213034.GA2545@nevyn.them.org> <3E3AF1DC.firstname.lastname@example.org> <20030131223639.GA3585@nevyn.them.org>
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.
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.
>If the consensus is "no, that's too stupid to be allowed to live", then
>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.