From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106330 invoked by alias); 30 Oct 2015 11:02:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 106321 invoked by uid 89); 30 Oct 2015 11:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Oct 2015 11:02:03 +0000 Received: from hogfather.0x04.net (89-65-84-110.dynamic.chello.pl [89.65.84.110]) by xyzzy.0x04.net (Postfix) with ESMTPS id 8F284400E3; Fri, 30 Oct 2015 12:02:17 +0100 (CET) Received: from [192.168.1.104] (89-76-92-82.dynamic.chello.pl [89.76.92.82]) by hogfather.0x04.net (Postfix) with ESMTPSA id C5891580092; Fri, 30 Oct 2015 12:02:00 +0100 (CET) Subject: Re: [RFC][PATCH][PR 18376] gdb: Add process record and replay support for s390. To: Ulrich Weigand References: <20151030103938.99AE45C3D@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56334E28.8010400@0x04.net> Date: Fri, 30 Oct 2015 15:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151030103938.99AE45C3D@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2015-10/txt/msg00756.txt.bz2 On 30/10/15 11:39, Ulrich Weigand wrote: > Marcin KoÅcielnicki 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 >