This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: dwarf2-frame.c question for maintainers
On Wed, 2004-07-14 at 12:28, Andrew Cagney wrote:
> >>> How come extract_typed_address, in read_reg, doesn't sign extend?
> >
> >
> > I should have explained that. It does. However extract_typed_address is
> > incorrect because it makes the invalid assumption that sizeof(address)
> > == sizeof(register). So that has to go and be replaced with something
> > like
> > extract_signed_integer (buf, register_size (current_gdbarch, regnum));
>
> You mean the builtin_type_void_data_ptr parameter to
> extract_typed_address? Ah.
>
> I see builtin_type_void_data_ptr dates back to 1.1 (Mark?). It could
> instead use the register's type?
extract_typed_address calls extract_[un]signed_integer with size =
TYPE_LENGTH of builtin_type_void_data_ptr.
Here's exactly what I am seeing. Maybe you can tell me if read_reg is
the problem.
For example big-endian Mips, with o64 or (eabi and mlong32):
(registers are 64 bits and pointers are 32 bits)
read_reg calls frame_unwind_register (next_frame, regnum, buf)
after that, buf has something like ffffffff801fffb8
Now if you do extract_typed_address(), it knows addresses are 4 bytes
and returns 0xffffffff sign extended to 0xfffffffffffffff
If instead, you call extract_[un]signed_integer((buf, register_size
(current_gdbarch, regnum)), it returns 0xffffffff801fffb8
The real problem here is the the size. AFAICT, sign-extension here is
unimportant; I get the same test results calling
extract_unsigned_integer in read_reg() for mips, because, as you can
see, nothing needs extending, just the whole register needs read.
However, I can't prove that is always the case because I am not familiar
enough with the code.
--
Martin M. Hunt <hunt@redhat.com>
Red Hat Inc.