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

Andreas Arnez
2015-05-06T18:16:48Z

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.