Re: [PATCH] Clear upper bits during sign extension

[Yao Qi <yao@codesourcery.com>]

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 (齐尧)