From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15333 invoked by alias); 7 Jun 2013 16:44:55 -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 15300 invoked by uid 89); 7 Jun 2013 16:44:55 -0000 X-Spam-SWARE-Status: No, score=-7.8 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; Fri, 07 Jun 2013 16:44:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r57GilZP019421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 12:44:47 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r57Gik52017644; Fri, 7 Jun 2013 12:44:46 -0400 Message-ID: <51B20DFD.8040805@redhat.com> Date: Fri, 07 Jun 2013 16: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: gdb-patches@sourceware.org, Ulrich Weigand Subject: Re: [RFA/RFT PATCH 0/3] Add TDB regset support References: <87fvwu5937.fsf@br87z6lw.de.ibm.com> <51B1F629.5070006@redhat.com> <87li6lud1m.fsf@br87z6lw.de.ibm.com> In-Reply-To: <87li6lud1m.fsf@br87z6lw.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00168.txt.bz2 On 06/07/2013 04:59 PM, Andreas Arnez wrote: > Pedro Alves writes: > >> Why isn't this exposed as a new target description that includes the >> new register set? > > It would require extracting the hardware capabilities from the core > file's auxiliary vector in order to distinguish between platforms with > and without the transactional-execution facility. I guess it could be > done, but I didn't consider it that important. You might not need to look at the auxv. Return the right tdesc depending on presence of bfd sections. See ppc_linux_core_read_description. > Do you see any problems with the current approach? > --- gdb.orig/gdb/regformats/s390-linux64v2.dat > +++ gdb/gdb/regformats/s390-linux64v2.dat > @@ -72,3 +72,23 @@ expedite:r14l,r15l,pswa > 32:orig_r2 > 32:last_break > 32:system_call > +64:tdb0 > +64:tac > +64:tct > +64:atia > +64:tr0 > +64:tr1 > +64:tr2 > +64:tr3 > +64:tr4 > +64:tr5 > +64:tr6 > +64:tr7 > +64:tr8 > +64:tr9 > +64:tr10 > +64:tr11 > +64:tr12 > +64:tr13 > +64:tr14 > +64:tr15 If you connect a 7.6 GDB without this patch to a new GDBserver that sends this extended regdat, I believe GDB will complain with "Remote 'g' packet reply is too long", even if the target actually doesn't support TDB. You should really add support for TDB to GDBserver too, before calling all this done. You're extending the remote register buffer with an optional feature, and in future when another alternative register set comes along that replaces this one, we're in trouble, as we won't be able to tell which is which (without ugly hacks). See how Ulrich handled this last time: http://sourceware.org/ml/gdb-patches/2011-12/msg00005.html -- Pedro Alves