Re: [PATCH] Clear upper bits during sign extension

Yao Qi
2014-12-30T09:20:13Z

Pedro Alves <palves@redhat.com> writes:

> This seems to me to paper over an issue elsewhere, and is likely
> to paper over issues as gdb_sign_extend is used more throughout.
>
> I'm not immediately familiar with all the conditions indirect_pieced_value
> is called, but going by the comment quoted, I think the root issue
> might be that we shouldn't use value_as_address in the first place,
> but something like unpack_long directly.

indirect_pieced_value is called by value_ind, in which its argument ARG1
should be regarded as an address, IMO.

#0 indirect_pieced_value (value=0x8af0fd8) at ../../../git/gdb/dwarf2loc.c:2006
#1 0x081d99fa in value_ind (arg1=0x8af0fd8) at ../../../git/gdb/valops.c:1548
#2 0x081de7f2 in value_subscript (array=0x8b41678, index=-2) at ../../../git/gdb/valarith.c:181

See value_ind's comment:

/* Given a value of a pointer type, apply the C unary * operator to
it. */

struct value *
value_ind (struct value *arg1)

>
> E.g., I don't see how it makes sense to interpret -2 as an address
> on spu, which ends up calling:

-2 is *not* the address in this case. The address is 0xfffffffe, and
sign extended to 64-bit (0xfffffffffffffffe) on MIPS target.

>
> static CORE_ADDR
> spu_integer_to_address (struct gdbarch *gdbarch,
> struct type *type, const gdb_byte *buf)
> {
> int id = spu_gdbarch_id (gdbarch);
> ULONGEST addr = unpack_long (type, buf);
>
> return SPUADDR (id, addr);
> }

Sorry, I don't understand how is gdbarch_integer_to_address hook related
to this problem. The address (0xfffffffe) is the address of synthetic
pointer, instead of the actual address.

--
Yao (齐尧)