From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25488 invoked by alias); 13 Jun 2013 14:27:41 -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 25479 invoked by uid 89); 13 Jun 2013 14:27:41 -0000 X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 13 Jun 2013 14:27:40 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5DEQAT6013708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 10:26:10 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5DEQ8u7019553; Thu, 13 Jun 2013 10:26:08 -0400 Message-ID: <51B9D67E.1080207@redhat.com> Date: Thu, 13 Jun 2013 14:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andreas Arnez 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> In-Reply-To: <878v2e8ead.fsf@br87z6lw.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00313.txt.bz2 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. ;-) 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. If you had a control register to check, there would be no need to zero out registers. >> 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. 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? 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. -- Pedro Alves