Re: dwarf2-frame.c question for maintainers

["Martin M. Hunt" <hunt at redhat dot com>]

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.