From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11410 invoked by alias); 28 May 2014 17:36:47 -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 11395 invoked by uid 89); 28 May 2014 17:36:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 28 May 2014 17:36:44 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 May 2014 18:36:40 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 May 2014 18:36:38 +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 2C0EC17D804E for ; Wed, 28 May 2014 18:37:53 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s4SHabfs1442298 for ; Wed, 28 May 2014 17:36:37 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 s4SHabOI028691 for ; Wed, 28 May 2014 11:36:37 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-188.boeblingen.de.ibm.com [9.152.212.188]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s4SHabPv028687; Wed, 28 May 2014 11:36:37 -0600 From: Andreas Arnez To: Yao Qi Cc: , Mark Kettenis Subject: Re: [PATCH 00/12] Regset rework preparations part 2 References: <1401122208-2481-1-git-send-email-arnez@linux.vnet.ibm.com> <5383FE52.7040404@codesourcery.com> Date: Wed, 28 May 2014 17:36:00 -0000 In-Reply-To: <5383FE52.7040404@codesourcery.com> (Yao Qi's message of "Tue, 27 May 2014 10:54:10 +0800") Message-ID: <87k3956c0q.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: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14052817-1948-0000-0000-000008F8905C X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00694.txt.bz2 On Tue, May 27 2014, Yao Qi wrote: > On 05/27/2014 12:36 AM, Andreas Arnez wrote: >> This part adds a collect_regset method to all Linux regsets where it >> had been missing. This is necessary, but not sufficient, to make the >> "gcore" command multi-arch capable for the affected targets. When >> this part is approved, I can provide a follow-on patch set that fills >> the remaining gaps to multi-arch capable core file handling for all >> Linux targets. > > Your multi-arch core file handling patches can justify the changes in > this series. You don't have to post them, but descriptions on how > multi-arch core file handling needs such regset interface are useful. OK, let's try. The following description applies to GNU/Linux targets: 1. What's needed for multi-arch capable "gcore" functionality? With the current implementation (see linux_make_corefile_notes_1()), the gdbarch field 'core_regset_sections' must be set; it specifies the names and sizes of the corefile register note sections to be written. In addition, the gdbarch method 'regset_from_core_section' must assign a regset structure to each of the 'core_regset_sections'. And all the returned regsets must contain platform-independent 'collect_regset' methods. 1a. What if a target does not fulfil these requirements? If 'core_regset_sections' is missing, the current implementation falls back to the (deprecated) target method 'make_corefile_notes', implemented for generic GNU/Linux targets by linux_nat_make_corefile_notes(). This invokes the native-dependent fill_gregset() and fill_fpregset() global functions, or (if available) uses the 'collect_regset' methods for each of the regsets associated with ".reg" and ".reg2". In the latter case the sizes of the register note sections are derived from the type definitions 'gregset_t' and 'fpregset_t' in the native-dependent system header files. 2. What's needed for multi-arch capable core file reading? As above, the gdbarch method 'regset_from_core_section' must be set. The 'core_regset_sections' list is optional, and if not set, is assumed to consist of ".reg" and ".reg2". The register note sizes are retrieved from the core file. Each of the regsets returned by 'regset_from_core_section' must have a platform-independent 'supply_regset' method. 2a. What if a target does not fulfil these requirements? If 'regset_from_core_section' is missing, the current code falls back to the 'core_read_registers' method from the core_fns object that has been registered by deprecated_add_core_fns(). This 'core_read_register' method then calls one of the native-dependent global functions supply_gregset() or supply_fpregset(), as appropriate. (4) What does the series at hand provide, and how about the follow-on series? This series defines 'collect_regset' methods and, where missing, also the 'supply_regset' methods and 'regset_from_core_section'. Since it does not set 'core_regset_sections', "gcore" still falls back to the native-dependent approach, but should at least use the new 'collect_regset' methods. Core file *reading* should be made multi-arch capable with this series already. My follow-on series merges 'core_regset_sections' with 'regset_from_core_section' and defines the merged method for all GNU/Linux targets.