This is the mail archive of the 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 05/24/2017 11:20 AM, Alan Hayward wrote:

>>> Meanwhile raw_collect_integer doesn’t need a signed parameter:
>> Wouldn't we need to support ADDR_LEN larger than the register size?
> This might be me misunderstanding gdb,
> But I assumed that addr would always be shorter than the register size.
> If addr is bigger than the register size then the most significant bits will
> be chopped off (including the sign), which I think would be a bad idea?

Yeah, the case of a 32-bit register being given a 64-bit slot in a ptrace
register buffer is actually not unheard of.  For example the
segment registers on x86-64 (cs, ss, ds, etc.) are 32-bit in
gdb's register cache, but Linux ptrace transfers them as 64-bit
[see /usr/include/sys/reg.h].  I'm not exactly sure whether
in such cases we end up needing to sign/zero extend when copying
back, or whether the kernel ignores the upper bits.  I think that
on x86 we just copy the lower 4 bytes and leave the upper ones as
they were, so probably the latter.  The MIPS architecture is special
around addresses being signed though, and given the existing code,
I'd play it safe and keep the collect/store functions mirrors - if
one truncates, the other fills/extends, and vice versa.  There's also

  /* Is the target using 64-bit raw integer registers but only
     storing a left-aligned 32-bit value in each?  */
  int mips64_transfers_32bit_regs_p;

which most probably doesn't apply in this case (FreeBSD, while
I think that was originally added for remote), but it compounds in
the weirdness.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]