From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17099 invoked by alias); 13 Jun 2013 11:02:18 -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 17088 invoked by uid 89); 13 Jun 2013 11:02:18 -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 e06smtp16.uk.ibm.com (HELO e06smtp16.uk.ibm.com) (195.75.94.112) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 13 Jun 2013 11:02:17 +0000 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Jun 2013 11:57:19 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 13 Jun 2013 11:57:17 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 527AA17D805A for ; Thu, 13 Jun 2013 12:03:33 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5DB20Lu49676338 for ; Thu, 13 Jun 2013 11:02:00 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r5DB22qC022150 for ; Thu, 13 Jun 2013 07:02:03 -0400 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r5DB22Bb022122; Thu, 13 Jun 2013 07:02:02 -0400 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> Date: Thu, 13 Jun 2013 12:23:00 -0000 In-Reply-To: <51B99143.3080808@redhat.com> (Pedro Alves's message of "Thu, 13 Jun 2013 10:30:43 +0100") Message-ID: <878v2e8ead.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: 13061310-3548-0000-0000-000005AA0F2C X-SW-Source: 2013-06/txt/msg00309.txt.bz2 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. > 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.