Message ID | 20180704001518.27593-1-jimw@sifive.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 18321 invoked by alias); 4 Jul 2018 00:16:04 -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 17928 invoked by uid 89); 4 Jul 2018 00:15:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:689, Hook, sk:riscv_r, HX-HELO:sk:mail-pl X-HELO: mail-pl0-f45.google.com Received: from mail-pl0-f45.google.com (HELO mail-pl0-f45.google.com) (209.85.160.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jul 2018 00:15:42 +0000 Received: by mail-pl0-f45.google.com with SMTP id 31-v6so1774800plc.4 for <gdb-patches@sourceware.org>; Tue, 03 Jul 2018 17:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=from:to:cc:subject:date:message-id; bh=oBlm18lZr8gxe0hZW0PdBDCPF1LSP1qmM08vOYyFIbM=; b=R1z/sBJaeBJWeA/WvkCPC/NjLGBRdNnWnYdKnW1iMsxy2GEq8R8C24cgLJ2MoKvQAU /byyR1fQXRJU6f9gWXSEx8Xl3r6GZ704i99v4FmRiYS6aGuNJDxCHZ4o6hPCnHnkriyE 1OuHBg/kGhSrD4v5Epw8oj/YT+KL4kXyR0ZgzbLKuU8MmRUUMk59DATwbSjASTfwOYJt g84wr3Vh6Yo9V5pXM4e7u0yaoWygmml7QrNdrJByYj5EhfynXxuyJetAHiOcC8YZol68 uh6vtAGrGWn/X2Fw1fAgf0UeAx0Mr9pA5fKCzIilwDd2UlCNRajLnuZyrBvppKGCod6o HQSg== Return-Path: <jimw@sifive.com> Received: from rohan.internal.sifive.com ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id o5-v6sm3912134pgd.24.2018.07.03.17.15.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 17:15:25 -0700 (PDT) From: Jim Wilson <jimw@sifive.com> To: gdb-patches@sourceware.org Cc: andrew.burgess@embecosm.com, Jim Wilson <jimw@sifive.com> Subject: [PATCH] RISC-V: Add osabi support. Date: Tue, 3 Jul 2018 17:15:18 -0700 Message-Id: <20180704001518.27593-1-jimw@sifive.com> |
Commit Message
Jim Wilson
July 4, 2018, 12:15 a.m. UTC
This adds the osabi init call that the linux native port needs. gdb/ * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. --- gdb/riscv-tdep.c | 3 +++ 1 file changed, 3 insertions(+)
Comments
* Jim Wilson <jimw@sifive.com> [2018-07-03 17:15:18 -0700]: > This adds the osabi init call that the linux native port needs. > > gdb/ > * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. I'm happy with this patch, but again wonder if this should be part of a sequence that adds OS support? Thanks, Andrewx > --- > gdb/riscv-tdep.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c > index 154567136e..1b941eee55 100644 > --- a/gdb/riscv-tdep.c > +++ b/gdb/riscv-tdep.c > @@ -2562,6 +2562,9 @@ riscv_gdbarch_init (struct gdbarch_info info, > user_reg_add (gdbarch, riscv_register_aliases[i].name, > value_of_riscv_user_reg, &riscv_register_aliases[i].regnum); > > + /* Hook in OS ABI-specific overrides, if they have been registered. */ > + gdbarch_init_osabi (info, gdbarch); > + > return gdbarch; > } > > -- > 2.17.1 >
On 7/4/18 2:11 AM, Andrew Burgess wrote: > * Jim Wilson <jimw@sifive.com> [2018-07-03 17:15:18 -0700]: > >> This adds the osabi init call that the linux native port needs. >> >> gdb/ >> * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. > > I'm happy with this patch, but again wonder if this should be part of > a sequence that adds OS support? I would be happy to have these bits go in actually as I will probably start working on FreeBSD RISC-V support in the near future (albeit using QEMU as my test environment for now). Having the riscv-tdep.c changes upstream will make that easier rather than either duplicating that work or having to temporarily pull it into my own branches.
* John Baldwin <jhb@FreeBSD.org> [2018-07-05 15:25:54 -0700]: > On 7/4/18 2:11 AM, Andrew Burgess wrote: > > * Jim Wilson <jimw@sifive.com> [2018-07-03 17:15:18 -0700]: > > > >> This adds the osabi init call that the linux native port needs. > >> > >> gdb/ > >> * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. > > > > I'm happy with this patch, but again wonder if this should be part of > > a sequence that adds OS support? > > I would be happy to have these bits go in actually as I will probably start > working on FreeBSD RISC-V support in the near future (albeit using > QEMU as my test environment for now). Having the riscv-tdep.c changes > upstream will make that easier rather than either duplicating that work > or having to temporarily pull it into my own branches. In terms of the code content of this patch (and the other one I commented on) I'm perfectly happy. However, I don't feel I'm qualified to give the OK to merge these given the original push back against merging unused code. I'd rather a global maintainer say yes or no. Thanks, Andrew > > -- > John Baldwin
On 2018-07-06 17:39, Andrew Burgess wrote: > * John Baldwin <jhb@FreeBSD.org> [2018-07-05 15:25:54 -0700]: > >> On 7/4/18 2:11 AM, Andrew Burgess wrote: >> > * Jim Wilson <jimw@sifive.com> [2018-07-03 17:15:18 -0700]: >> > >> >> This adds the osabi init call that the linux native port needs. >> >> >> >> gdb/ >> >> * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. >> > >> > I'm happy with this patch, but again wonder if this should be part of >> > a sequence that adds OS support? >> >> I would be happy to have these bits go in actually as I will probably >> start >> working on FreeBSD RISC-V support in the near future (albeit using >> QEMU as my test environment for now). Having the riscv-tdep.c changes >> upstream will make that easier rather than either duplicating that >> work >> or having to temporarily pull it into my own branches. > > In terms of the code content of this patch (and the other one I > commented on) I'm perfectly happy. > > However, I don't feel I'm qualified to give the OK to merge these > given the original push back against merging unused code. I'd rather > a global maintainer say yes or no. I think this is fine. That line is kind of standard boilerplate in gdbarch_init methods. The <arch>-tdep.c file is not really supposed to know what osabi variants exist above it, so it's ok to call it "just in case". It's not like we are adding one thousand lines of not-yet-used code :). Simon
On Fri, Jul 6, 2018 at 6:53 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote: >>> >> This adds the osabi init call that the linux native port needs. >>> >> >>> >> gdb/ >>> >> * riscv-tdep.c (riscv_gdbarch_init): Call gdbarch_init_osabi. This was approved by Andrew (RISC-V) and Simon (global) so I committed it. Jim
diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index 154567136e..1b941eee55 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -2562,6 +2562,9 @@ riscv_gdbarch_init (struct gdbarch_info info, user_reg_add (gdbarch, riscv_register_aliases[i].name, value_of_riscv_user_reg, &riscv_register_aliases[i].regnum); + /* Hook in OS ABI-specific overrides, if they have been registered. */ + gdbarch_init_osabi (info, gdbarch); + return gdbarch; }