From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20853 invoked by alias); 16 Jul 2013 16:03:15 -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 20841 invoked by uid 89); 16 Jul 2013 16:03:15 -0000 X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO e06smtp15.uk.ibm.com) (195.75.94.111) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 16 Jul 2013 16:03:09 +0000 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 16 Jul 2013 16:58:02 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 16 Jul 2013 16:58:01 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0F46D2190023 for ; Tue, 16 Jul 2013 17:06:59 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6GG2mRY38404348 for ; Tue, 16 Jul 2013 16:02:48 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 r6GG2wFK008009 for ; Tue, 16 Jul 2013 10:02:58 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id r6GG2up6007938; Tue, 16 Jul 2013 10:02:56 -0600 Message-Id: <201307161602.r6GG2up6007938@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 16 Jul 2013 18:02:56 +0200 Subject: Re: [ping 2] [RFA][PATCH v4 0/5] Add TDB regset support To: arnez@linux.vnet.ibm.com (Andreas Arnez) Date: Tue, 16 Jul 2013 16:03:00 -0000 From: "Ulrich Weigand" Cc: lgustavo@codesourcery.com, gdb-patches@sourceware.org In-Reply-To: <87wqoqle5v.fsf@br87z6lw.de.ibm.com> from "Andreas Arnez" at Jul 16, 2013 05:26:04 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13071615-0342-0000-0000-000005996185 X-SW-Source: 2013-07/txt/msg00365.txt.bz2 Andreas Arnez wrote: > Would it help to merge the iterator function with the logic of > ppc_regset_from_core_section(), like outlined in the patch below? > > I see the following advantages: > > - One less gdbarch function needed: gdbarch_regset_from_core_section > becomes obsolete. > > - The regset description is more "self-contained": it now includes the > name, description, and size. > > - Even less code than the previous version, all condensed in a single > function. In general, I agree it would be nice to merge the information from core_regset_section into struct regset itself, for the reasons you mention. However, one reason to keep them distinct in the past has been that many platforms do not actually provide a core_regset_section, only a struct regset; in particular, the sizes of the regsets are not there. These are the platforms that fall back to sizeof (gregset) etc. for native code and do not support cross-corefile debugging and/or generation. It has always been a goal to provide core_regset_section info for all platforms and get rid of the various legacy methods, but so far this has not been done. As usual, one of the problem is that you'd need to test on those platforms, which may be hard to do. Your patch below doesn't show the common code changes, so I'm not sure how you planned to handle legacy platforms. I guess it might be possible to detect them using zero markers in those fields ... As an aside, I'm wondering: > + res = cb (tdep->wordsize == 4 ? > + &ppc32_linux_gregset : &ppc64_linux_gregset, > + cb_data); > + if (!res) > + res = cb (&ppc32_linux_fpregset, cb_data); > + if (!res && have_altivec) > + res = cb (&ppc32_linux_vrregset, cb_data); > + if (!res && have_vsx) > + cb (&ppc32_linux_vsxregset, cb_data); Why does the callback need to return a flag that has to be handled by the caller? If there is indeed a requirement for treating error conditions specially, couldn't the callback store error data in the cb_data and handle it on subsequent calls? This would make the gdbarch implementations in the targets yet easier and simpler to write, something along the lines of: if (tdep->wordsize == 4) cb (&ppc32_linux_gregset, cb_data); else cb (&ppc64_linux_gregset, cb_data); cb (&ppc32_linux_fpregset, cb_data); if (have_altivec) cb (&ppc32_linux_vrregset, cb_data); if (have_vsx) cb (&ppc32_linux_vsxregset, cb_data); Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com