This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Regression on gdb.base/checkpoint.exp on S/390
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Wed, 06 May 2015 20:16:38 +0200
- Subject: Re: Regression on gdb.base/checkpoint.exp on S/390
- Authentication-results: sourceware.org; auth=none
- References: <87fvwu5937 dot fsf at br87z6lw dot de dot ibm dot com> <87txlavxmd dot fsf at br87z6lw dot de dot ibm dot com> <87mw1ig7h3 dot fsf_-_ at redhat 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.