Re: [RFC][PATCH][PR 18376] gdb: Add process record and replay support for s390.

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Marcin KoÃ?cielnicki <koriakin at 0x04 dot net> wrote:

Many thanks for working on this!

> Almost all off the unpriviledged instruction set is supported.  I skipped most
> of chapter 10 (z/Series principles of operations) instructions, as well as
> CFC/UPT, since they're never used on Linux.  Transactional execution and the
> associated instructions are also not supported, since it's impossible to trace
> them.

This sounds find to me.   There may be an issue (which we recently found on
PowerPC as well) with very recent glibc versions that attempt to use
transactions for lock elision.  If every transactional instruction will
cause process record to abort, this may happen during many common glibc
routines in that case.  A simple way to fix this might be to accept at
least TBEGIN for process recording, assuming that it will always fail.
(That failure ought to trigger the non-transactional fallback in glibc.)

> There's a problem in handling of the partial-execution instructions that can
> write to the memory (like MVCLE): they're supposed to write an arbitrarily
> sized area of data, but can stop at any moment and ask to be restarted.
> Since at the time of record I cannot have a clue how much of the block will
> actually be written this iteration, I'm forced to record all of it (which can
> be megabytes or worse), but the CPU I tested on actually processes only 4kiB
> on each iteration - meaning that recording MVCLE and friends has O(n**2)
> time and memory complexity!
> 
> I suppose the best way to solve that problem would be to force restarting
> the affected instructions when they are recorded (without re-recording them)
> until they give a CC other than 3.  From the program's point of view, this is
> indistinguishable from a CPU that just decided to process the full buffer
> in one step.  Unfortunately, that'd involve an unpretty layering violation
> in gdb code.

Right, that's a bit of a problem.  One way might to do something similar
as we do with atomic instructions on PowerPC: use the software single-step
mechanism to always skip over the "MVCLE; JO" block in one go.  This means
we'd have to provide a gdbarch_software_single_step routine that would
recognize a partial-execution instruction followed by a branch back,
and install a software single-step breakpoint after that branch, instead
of using hardware single-stepping.  This will mean that the recording
logic would likewise see the pair as a "single" instruction.  See the
ppc_deal_with_atomic_sequence routine for comparison.

We probably want to do that only if we're currently recording, though.
Maybe we'll have to add a new target_record_is_recording callback to
parallel the existing target_record_is_replaying to make that
distinction.

> The gdb.reverse testsuite passes after this commit on both s390-linux and
> s390x-linux (except for the waitpid test, as mentioned in the record fixes
> thread).

Excellent.  From the follow-on discussions on the list, it seems the
waitpid issue is now also resolved?

B.t.w. to excercise more instructions, it might be good to re-run the
testsuite with various -march settings, in particular -march=z13 (using
a recent enough compiler).

> I'd appreciate a review and suggestions about the partial execution issue.

At a first glance this patch looks very good.  I'm still going through
reviewing all the details ...

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com