Re: [PATCH 2/2] S390: Fix gdbserver support for TDB

[Pedro Alves <palves at redhat dot com>]

On 12/02/2014 07:18 PM, Andreas Arnez wrote:
> On Tue, Dec 02 2014, Pedro Alves wrote:
> 
>> On 12/01/2014 06:15 PM, Andreas Arnez wrote:
>>
>>> But after a quick grep through the Linux kernel it seems that there are
>>> currently only two regsets for which ENODATA can be returned: the TDB on
>>> S390 and the iWMMXt state on ARM.
>>
>> I've pushed the PowerPC transactional memory ptrace support toward modeling
>> from s390, and the current patches (iterating under review) will return
>> ENODATA too, but for the exact same scenario, so sounds like we'll be
>> good there too.
>>
>>> diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c
>>> index 8b72523..42dd521 100644
>>> --- a/gdb/gdbserver/linux-arm-low.c
>>> +++ b/gdb/gdbserver/linux-arm-low.c
>>> @@ -199,6 +199,13 @@ arm_store_wmmxregset (struct regcache *regcache, const void *buf)
>>>    if (!(arm_hwcap & HWCAP_IWMMXT))
>>>      return;
>>
>> What are the conditions the ARM kernel checks to return
>> ENODATA for this regset?  I'd assume that it'd be the case of
>> the machine not really supporting iwmmxt, and thus the check
>> above already catching this.
> 
> Someone with more ARM background should probably answer this, but
> according to elf_set_personality in arch/arm/kernel/elf.c it seems that
> ENODATA is also returned if the binary is neither EABI nor softfloat,
> even if HWCAP_IWMXXT is set.

Looks like you're right.


>> Doesn't this mean a write attempt to such a read-only regset "succeeds"
>> silently instead of erroring?
>>
>> Does the test exercise this?  How does GDB/native behave?
> 
> Good point.  Both gdbserver and GDB silently "succeed".  I did not
> consider this a significant issue so far...  Any suggestions how to
> improve this behavior?

Hmm, thinking further, I think the main issue is that gdbserver
may get a single G packet to write the whole register buffer
to the target, and it'll get that whether the user explicitly
tried to change one of the read-only registers, or any other regular
register.  I think we'd have to augment the G packet with a way that
says "these values are don't care, I'm not actually writing
to these registers".  The read/'g' packet uses 'x' for unavailable
registers, maybe we could reuse that for writes/'G', something like
"G 00112233xxxx0022", meaning the registers at the offsets where we
have 'x's shouldn't be written.

Anyway, if GDB behaves the same, let's not worry about this now.

Thanks,
Pedro Alves