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

["Marcin Kościelnicki" <koriakin@0x04.net>]

On 30/10/15 11:39, Ulrich Weigand wrote:
> 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.)

I'll do that, but I have no way of testing it - I only have access to a 
z196 machine.

>> 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.

Sounds like a good plan, I'll try implementing that.
>
>> 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?

Well, the test passes now, though there's definitely still a bug 
somewhere in fork handling (BZ 19187).
>
> 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).
>
Unfortunately, I don't have access to the hardware for -march=z13, but 
I'll try the ones I can.

>> 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 for looking at this!
>
> Thanks,
> Ulrich
>