Message ID | 20180606151629.36602-11-alan.hayward@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 104459 invoked by alias); 6 Jun 2018 15:17:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 104309 invoked by uid 89); 6 Jun 2018 15:17:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1317 X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr10071.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.107.1.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Jun 2018 15:17:27 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; Received: from C02TF0U7HF1T.arm.com (217.140.96.140) by AM4PR0802MB2132.eurprd08.prod.outlook.com (2603:10a6:200:5c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Wed, 6 Jun 2018 15:16:56 +0000 From: Alan Hayward <alan.hayward@arm.com> To: gdb-patches@sourceware.org Cc: nd@arm.com, Alan Hayward <alan.hayward@arm.com> Subject: [PATCH v2 10/10] Remove reg2 section from Aarch64 SVE cores Date: Wed, 6 Jun 2018 16:16:29 +0100 Message-Id: <20180606151629.36602-11-alan.hayward@arm.com> In-Reply-To: <20180606151629.36602-1-alan.hayward@arm.com> References: <20180606151629.36602-1-alan.hayward@arm.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: CWLP265CA0083.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:50::23) To AM4PR0802MB2132.eurprd08.prod.outlook.com (2603:10a6:200:5c::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: AM4PR0802MB2132: NoDisclaimer: True X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-MS-Exchange-SenderADCheck: 1 X-Forefront-PRVS: 06952FC175 Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Office365-Filtering-Correlation-Id: 4925d689-d987-4737-220d-08d5cbc08acd X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2018 15:16:56.2839 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4925d689-d987-4737-220d-08d5cbc08acd X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2132 X-IsSubscribed: yes |
Commit Message
Alan Hayward
June 6, 2018, 3:16 p.m. UTC
reg2 sections in SVE binaries will cause gdb to segfault on loading due to miscalculating the register size. For now, simply remove reg2 from SVE core files. This results in core files without any vector/float register. Full core support for SVE will come in a later set of patches. 2018-06-06 Alan Hayward <alan.hayward@arm.com> gdb/ * aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections): Check for SVE. --- gdb/aarch64-linux-tdep.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On 2018-06-06 11:16 AM, Alan Hayward wrote: > reg2 sections in SVE binaries will cause gdb to segfault on loading > due to miscalculating the register size. > > For now, simply remove reg2 from SVE core files. This results in > core files without any vector/float register. Full core support > for SVE will come in a later set of patches. > > 2018-06-06 Alan Hayward <alan.hayward@arm.com> > > gdb/ > * aarch64-linux-tdep.c > (aarch64_linux_iterate_over_regset_sections): Check for SVE. > --- > gdb/aarch64-linux-tdep.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index 96dc8a1132..b05bb49ae8 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -227,10 +227,13 @@ aarch64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch, > void *cb_data, > const struct regcache *regcache) > { > + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > + > cb (".reg", AARCH64_LINUX_SIZEOF_GREGSET, &aarch64_linux_gregset, > NULL, cb_data); > - cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, > - NULL, cb_data); > + if (!tdep->has_sve ()) > + cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, > + NULL, cb_data); > } > > /* Implement the "core_read_description" gdbarch method. SVE not yet > IIUC, this doesn't remove existing features? If a program was using the neon registers, they will still be available? If so, this LGTM. Simon
> On 11 Jun 2018, at 03:47, Simon Marchi <simark@simark.ca> wrote: > > On 2018-06-06 11:16 AM, Alan Hayward wrote: >> reg2 sections in SVE binaries will cause gdb to segfault on loading >> due to miscalculating the register size. >> >> For now, simply remove reg2 from SVE core files. This results in >> core files without any vector/float register. Full core support >> for SVE will come in a later set of patches. >> >> 2018-06-06 Alan Hayward <alan.hayward@arm.com> >> >> gdb/ >> * aarch64-linux-tdep.c >> (aarch64_linux_iterate_over_regset_sections): Check for SVE. >> --- >> gdb/aarch64-linux-tdep.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c >> index 96dc8a1132..b05bb49ae8 100644 >> --- a/gdb/aarch64-linux-tdep.c >> +++ b/gdb/aarch64-linux-tdep.c >> @@ -227,10 +227,13 @@ aarch64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch, >> void *cb_data, >> const struct regcache *regcache) >> { >> + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); >> + >> cb (".reg", AARCH64_LINUX_SIZEOF_GREGSET, &aarch64_linux_gregset, >> NULL, cb_data); >> - cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, >> - NULL, cb_data); >> + if (!tdep->has_sve ()) >> + cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, >> + NULL, cb_data); >> } >> >> /* Implement the "core_read_description" gdbarch method. SVE not yet >> > > IIUC, this doesn't remove existing features? If a program was using the neon > registers, they will still be available? > > If so, this LGTM. > With this patch, on SVE systems, gdb will create cores without any sve OR neon registers. Whilst not ideal that’s better than gdb segfaulting. ...However, this got me thinking. SVE core files produced by the kernel will have both FP and SVE sections, even though the FP section is essentially redundant. So, gdb does need to support that. I'm working my way through fixing that. It’ll mostly be a change to regcache to handle mismatched register sizes to core file slot sizes. I’ll drop this patch for now, and will hopefully have a new patch posted Tuesday. Alan.
diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c index 96dc8a1132..b05bb49ae8 100644 --- a/gdb/aarch64-linux-tdep.c +++ b/gdb/aarch64-linux-tdep.c @@ -227,10 +227,13 @@ aarch64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch, void *cb_data, const struct regcache *regcache) { + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); + cb (".reg", AARCH64_LINUX_SIZEOF_GREGSET, &aarch64_linux_gregset, NULL, cb_data); - cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, - NULL, cb_data); + if (!tdep->has_sve ()) + cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, &aarch64_linux_fpregset, + NULL, cb_data); } /* Implement the "core_read_description" gdbarch method. SVE not yet