From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115625 invoked by alias); 2 Nov 2015 20:33:25 -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 115608 invoked by uid 89); 2 Nov 2015 20:33:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp05.uk.ibm.com Received: from e06smtp05.uk.ibm.com (HELO e06smtp05.uk.ibm.com) (195.75.94.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 02 Nov 2015 20:33:23 +0000 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Nov 2015 20:33:19 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 Nov 2015 20:33:18 -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 1828B17D8056 for ; Mon, 2 Nov 2015 20:33:33 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tA2KXIW458851568 for ; Mon, 2 Nov 2015 20:33:18 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tA2KXIUn020594 for ; Mon, 2 Nov 2015 13:33:18 -0700 Received: from oc7340732750.ibm.com (icon-9-164-158-208.megacenter.de.ibm.com [9.164.158.208]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tA2KXH6S020589; Mon, 2 Nov 2015 13:33:17 -0700 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id F15282665; Mon, 2 Nov 2015 21:33:16 +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: Mon, 02 Nov 2015 20:33:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <1446491482-3703-1-git-send-email-koriakin@0x04.net> from "=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=" at Nov 02, 2015 08:11:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20151102203316.F15282665@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15110220-0021-0000-0000-000004AE10B6 X-SW-Source: 2015-11/txt/msg00045.txt.bz2 Marcin KoÅcielnicki wrote: > I have added pseudo-support for TBEGIN (just to let it abort and fallback), > as well as PPA and ETND (on the off-chance someone uses them). Excellent. > I have also found three missing break statements and fixed those. Huh, I didn't find those :-) I found a small number of issues (mostly cosmetic) ... review will follow shortly. > The second patch implements single-stepping over a MVCLE+JO pair (as well > as other partial-execution instructions that can write memory). I haven't > limitted it to record-only - AFAICT it doesn't cause any problems without > record (in fact, it should decrease context switches for large transfers), > but I'll restrict that if necessary. Well, I was thinking that if you manually single-step, you might want to see the actual machine behavior. That's why I suggested restricting the behavior to recording ... > As for the Uniersity of Syracuse machines, I do have access, and they are > only z196. Huh, I thought those were z13 ... I'll check whether there is a z13 available somewhere. > There's also an ambiguity in LCBB opcode documentation: it produces a 32-bit > unsigned result, but the text mentions storing it to the general register > (not to bits 32-63 of a general register, as is common for documentation > of proper 32-bit opcodes). I don't have a vector-supporting machine, so > I can't check what is correct. The patch goes the safe way and assumes > all 64 bits of GR can be changed. LCBB definitely only stores bits 32-63 of a general register. For other instructions, the PoP uses a wording like "the operand is treated as 32-bit unsigned integer" to indicate this; I think the wording for LCBB is different simply because there is no *G variant of the instruction. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com