This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 >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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |