From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21510 invoked by alias); 13 Jun 2013 17:16:07 -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 21501 invoked by uid 89); 13 Jun 2013 17:16:06 -0000 X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 13 Jun 2013 17:16:04 +0000 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Jun 2013 18:12:20 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 13 Jun 2013 18:12:18 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 122E91B0805D for ; Thu, 13 Jun 2013 18:16:00 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5DHFmeN50331772 for ; Thu, 13 Jun 2013 17:15:48 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r5DHFw2U032185 for ; Thu, 13 Jun 2013 11:15:59 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r5DHFwUF032181; Thu, 13 Jun 2013 11:15:58 -0600 From: Andreas Arnez To: Pedro Alves Cc: Mark Kettenis , gdb-patches@sourceware.org, Ulrich.Weigand@de.ibm.com Subject: Re: [PATCH v3 3/3] Dynamic core regset sections support References: <877ghzmkmj.fsf@br87z6lw.de.ibm.com> <8738sngy5e.fsf@br87z6lw.de.ibm.com> <201306121521.r5CFLvl9024858@glazunov.sibelius.xs4all.nl> <871u86e5gi.fsf@br87z6lw.de.ibm.com> <51B99143.3080808@redhat.com> <878v2e8ead.fsf@br87z6lw.de.ibm.com> <51B9D67E.1080207@redhat.com> Date: Thu, 13 Jun 2013 17:36:00 -0000 In-Reply-To: <51B9D67E.1080207@redhat.com> (Pedro Alves's message of "Thu, 13 Jun 2013 15:26:06 +0100") Message-ID: <87k3lyextd.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13061317-0542-0000-0000-000005894F40 X-SW-Source: 2013-06/txt/msg00316.txt.bz2 Pedro Alves writes: > On 06/13/2013 12:02 PM, Andreas Arnez wrote: >> Pedro Alves writes: >> >>>> Do you mean to always write the TDB regset into the core dump, like >>>> without the patch? And then add some logic such that GDB recognizes >>>> zero values in the register note section as invalid and clears the >>>> regset? Or do I misinterpret your suggestion? >>> >>> Not zero, but present them as unavailable/invalid. >> >> Not sure I understand your point here. *Presenting them* as unavailable >> is exactly what the patch does. > > Well, you were the one who brought zeros up. ;-) Zeros are written by gcore without the patch, because this is what a register note section happens to be filled with when the registers are actually unavailable. The patch avoids that and doesn't write the section at all. > Mark didn't seem to imply any connection between zeros and the > registers' validity, and I was reinforcing the idea. I'm not sure > what you meant by clearing, but that seemed to imply zeroing too. No, I meant marking unavailable. >>> Isn't there a control register GDB can read to check whether a >>> transaction is in progress (useful for both core and live debugging) ? >> >> No, the kernel indicates an interrupted transaction with the presence of >> the TDB regset. This applies to ptrace as well as to a core dump. My >> goal for gcore was to behave the same. > > I see... > > I tried to do a little investigation on s390 transactions. It's now > my understanding that these "registers" are really a memory block > whose address passed in by the user to the hardware when a transaction > is started with TBEGIN. There's a tbegin variant ("simple tbegin" ?) > that doesn't take such a tcb address, and I guess there's some way the > kernel coordinates with the hardware to know/specify where the tcb is > written to. Almost. There are two ways the TDB can get written. The way you describe is for a "normal" transaction abort. The other way is for an abort due to a program interruption, like an illegal instruction, or a breakpoint or watchpoint hit. In that case the hardware writes the "program-interruption TDB" to a fixed address, independently from any user-specified address. > I couldn't find the definite manual/document that explains what > exactly the TDB contains though (tdb0, atia, etc?), only references > like "If the transaction fails, the TDB is populated with lots of > information.". Cool, what is lots, though? :-) Do you have a pointer, > for my own education, and for the archives? See the z/Architecture Principles of Operation: http://publibfp.boulder.ibm.com/epubs/pdf/dz9zr009.pdf Specifically, refer to the section "Transactional-Execution Facility" in chapter 5, "Program Execution". > I was mildly wondering whether it wouldn't be a little better to > expose this through a new target object (and target_read/qXfer:read) > instead, and add a $_tdb convenience variable (similar to $_siginfo -- > p $_tdb; p $_tdb.atia, etc.). That'd mean no read of the TDB block > unless the user requested it, possibility to error out when outside a > transaction, and a way for the user to put the whole TDB in GDB's > value history. Interesting thought. There are probably pros and cons either way. The regset approach seemed most straightforward, because the kernel presents the program interruption TDB as a regset. Retrieving the TDB only on user request won't work in the long run, because it contains vital information for transaction debugging. I'm currently working on a GDB patch to exploit that.