From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9650 invoked by alias); 14 May 2014 12:13:36 -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 9534 invoked by uid 89); 14 May 2014 12:13:35 -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: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 14 May 2014 12:13:33 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 May 2014 13:13:30 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 May 2014 13:13:27 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 83AD2219004D for ; Wed, 14 May 2014 13:13:18 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s4ECDRnl62849142 for ; Wed, 14 May 2014 12:13:27 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s4ECDR0a014368 for ; Wed, 14 May 2014 06:13:27 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-188.boeblingen.de.ibm.com [9.152.212.188]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s4ECDQiK014336 for ; Wed, 14 May 2014 06:13:26 -0600 From: Andreas Arnez To: gdb-patches@sourceware.org Subject: [PING^2] [RFC 00/23] Regset rework preparations Date: Wed, 14 May 2014 12:13:00 -0000 Message-ID: <87fvkc8snt.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: 14051412-8372-0000-0000-000009AC88CE X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00200.txt.bz2 Although there was feedback for some of the patches in this series (https://sourceware.org/ml/gdb-patches/2014-04/msg00560.html), many are still uncommented. I'd really appreciate more feedback, particularly for the architecture-specific changes. So far the patches have been commented as follows. > * Patch 1 ("Constify regset structures"): Converts (unnecessarily) > non-constant static regsets to constant ones. Approved by Mark Kettenis: https://sourceware.org/ml/gdb-patches/2014-05/msg00037.html > * Patch 2 ("Remove 'arch' field from regset structure"): Removes the > only inherently dynamic field from the regset structure. Mark Kettenis suggested to split the initializers of the form "tdep = gdbarch_tdep (get_regcache_arch (...))" in two lines. This is done: https://sourceware.org/ml/gdb-patches/2014-05/msg00042.html > * Patch 3-8 and 10 ("Replace regset_alloc() invocations by static > regset structures."): Eliminate dynamic regset allocations and > replace them by static constant structures, now that regsets don't > carry dynamic data any more. This generally simplifies the code and > increases the similarity of regset definitions across architectures. Patch 5 (x86): Mark Kettenis suggested to keep i386_supply_gregset as a global function. This is done: https://sourceware.org/ml/gdb-patches/2014-04/msg00607.html Patch 10 (SPARC): Approved by Mark Kettenis: https://sourceware.org/ml/gdb-patches/2014-05/msg00039.html Patches 3, 4, 6, 7, 8 (AARCH64, ARM, MIPS, MN10300, and SCORE): No comments yet. > * Patch 9 ("SPARC: Rename register maps from "*regset" to "*regmap"): > Adjusts naming, to avoid name clashes in patch 10. Approved by Mark Kettenis: https://sourceware.org/ml/gdb-patches/2014-05/msg00038.html > * Patch 11 ("Drop regset_alloc()"): Removes the now-unused function. Approved by Mark Kettenis, but depends on patches 3-8: https://sourceware.org/ml/gdb-patches/2014-05/msg00040.html > * Patch 12 ("regcache: Add functions suitable for > regset_supply/collect"): Provides generic supply/collect functions, > such that architecture-specific logic can be reduced. There doesn't seem to be agreement on the map format for the generic supply/collect functions. See my latest comment on this: https://sourceware.org/ml/gdb-patches/2014-05/msg00043.html Any suggestions are welcome. Note that many of the remaining patches in this series depend on patch 12. > * Patch 13 ("S390: Migrate to regcache_supply/collect_regset"): > Exploits the new generic supply/collect functions from patch 12 for > S390. Such exploitation is likely possible by other architectures > as well; this patch provides an example. Depends on patch 12. Would be nice to get in, because it greatly simplifies the S/390 tdep code. > * Patch 14-21 ("Fill 'collect_regset' in regset structures"): Add the > 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. Some of these patches exploit the new > generic supply/collect functions from patch 12. No real new > functionality is provided, but an important prerequisite for > multi-arch capable core file handling is fulfilled. > > * Patch 22, 23 ("Define regset structures"): Define regset structures > for each of the Linux targets that lacked them before (M68K and > IA64). Exploit the new generic supply/collect functions from patch > 12. These patches should make core file reading (but not writing) > multi-arch capable for these targets. No feedback for any of these yet.