From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44712 invoked by alias); 30 Oct 2015 10:39:47 -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 44702 invoked by uid 89); 30 Oct 2015 10:39:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: e06smtp10.uk.ibm.com Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 30 Oct 2015 10:39:45 +0000 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Oct 2015 10:39:42 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 30 Oct 2015 10:39:40 -0000 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id B3AB117D805D for ; Fri, 30 Oct 2015 10:39:52 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t9UAddfZ6553904 for ; Fri, 30 Oct 2015 10:39:39 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t9UAdd7w018968 for ; Fri, 30 Oct 2015 04:39:39 -0600 Received: from oc7340732750.ibm.com (icon-9-164-156-174.megacenter.de.ibm.com [9.164.156.174]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t9UAdd98018948; Fri, 30 Oct 2015 04:39:39 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 99AE45C3D; Fri, 30 Oct 2015 11:39:38 +0100 (CET) Subject: Re: [RFC][PATCH][PR 18376] gdb: Add process record and replay support for s390. To: koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) Date: Fri, 30 Oct 2015 15:30:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) In-Reply-To: <1445863167-18314-1-git-send-email-koriakin@0x04.net> from "=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=" at Oct 26, 2015 01:39:27 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20151030103938.99AE45C3D@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15103010-0041-0000-0000-0000062AABDA X-SW-Source: 2015-10/txt/msg00754.txt.bz2 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.) > 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