Re: Regression on gdb.base/checkpoint.exp on S/390

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Tue, May 05 2015, Sergio Durigan Junior wrote:

> On Friday, June 07 2013, Andreas Arnez wrote:
>
>> S/390 regmap rework: Represent register maps in a less redundant and
>> more readable way.  Also remove some code repetition.
>
> Hey Andreas,
>
> As we discussed on private, this commit has caused the following
> regression on S/390 (31-bit):
>
>   $ make check RUNTESTFLAGS='--target_board=unix/-m31 gdb.base/checkpoint.exp'
>   Running ../../../gdb/gdb/testsuite/gdb.base/checkpoint.exp ...
>   FAIL: gdb.base/checkpoint.exp: restart 1 one
>   FAIL: gdb.base/checkpoint.exp: verify i 1 one
> [...]

Right.  This is caused by a misunderstanding on my side when I wrote
that patch.  In fill_gregset, I was under the assumption that the
"gregset" part of the REGCACHE is fully populated, since that's what
supply_gregset would do.  However, fill_gregset is also used within
s390_linux_store_inferior_registers, for merging the inferior's
registers with one (or all) of a regcache's registers.  And that is
invoked via regcache_raw_write in a loop for each register when doing
regcache_cpy.  Until the loop has finished, the destination regcache is
partially filled, and my assumption is broken.

I've tried a fix that avoids this assumption, and it works.  (I'll post
it soon.)

But I also wonder whether it's intended that each regcache_raw_write
results in two ptrace calls?  This seems quite inefficient, considering
that all inferior's registers could be modified at once.