Message ID | 20180808021734.7844-1-jimw@sifive.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 121029 invoked by alias); 8 Aug 2018 02:17:41 -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 121006 invoked by uid 89); 8 Aug 2018 02:17:40 -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=UD:configure.nat, ppclinuxo, NATDEPFILES, ppc-linux.o X-HELO: mail-oi0-f67.google.com Received: from mail-oi0-f67.google.com (HELO mail-oi0-f67.google.com) (209.85.218.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Aug 2018 02:17:39 +0000 Received: by mail-oi0-f67.google.com with SMTP id s198-v6so1103658oih.11 for <gdb-patches@sourceware.org>; Tue, 07 Aug 2018 19:17:39 -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:in-reply-to:references; bh=cVNCc/R6TP219LEbPpq+PaSp770ZrYijUTRfXO2g/wg=; b=Hg6wcsidJfpOXDCW4/Z2fNREjswvlkL5pv3YEPbUamCH5KnW6LvbTKeN/qOh83gGnA PDnplTgCxwQB8AqjeOaOXg+PaVb/Um8TOCDJp4Me/PThGJVWQGLz+fHapcvDiov51M6Z eIF1OrXxIteM+9bD45UVV5VW5x40AT8xX/3ZyrHcL8KJwkjYD51VHWqcj/yE6XcNSAoq uEgDJnOwjCb9wy7l4RsqCETo12PetzlbANlT7iLEbc2lZ5Or/FAkFRcLP5MWaX1JHxdE YdaPsH2dBc8c/WaPT1DwqquNGEsiqKkf/gVE5RxfSiywxjgcy+xeTn0JZzU4NrRVT8GE ewqw== Return-Path: <jimw@sifive.com> Received: from rohan.guest.sifive.com ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id o125-v6sm4794754oig.44.2018.08.07.19.17.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 19:17:37 -0700 (PDT) From: Jim Wilson <jimw@sifive.com> To: gdb-patches@sourceware.org Cc: Jim Wilson <jimw@sifive.com> Subject: [PATCH 5/5] RISC-V: Add configure support riscv*-linux*. Date: Tue, 7 Aug 2018 19:17:34 -0700 Message-Id: <20180808021734.7844-1-jimw@sifive.com> In-Reply-To: <CAFyWVaZYfm47vRseKpw+DX0CqD__BW7JydMohRrz_BpP5HYQrQ@mail.gmail.com> References: <CAFyWVaZYfm47vRseKpw+DX0CqD__BW7JydMohRrz_BpP5HYQrQ@mail.gmail.com> |
Commit Message
Jim Wilson
Aug. 8, 2018, 2:17 a.m. UTC
This adds the target and native configure support, and the NEWS entries for the new target and native configurations. gdb/ * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. * NEWS: Mention new GNU/Linux RISC-V target. * configure.host: Add riscv*-*-linux*. * configure.nat: Add riscv*. * configure.tgt: Add riscv*-*-linux*. --- gdb/Makefile.in | 4 ++++ gdb/NEWS | 8 ++++++++ gdb/configure.host | 2 ++ gdb/configure.nat | 4 ++++ gdb/configure.tgt | 6 ++++++ 5 files changed, 24 insertions(+)
Comments
* Jim Wilson <jimw@sifive.com> [2018-08-07 19:17:34 -0700]: > This adds the target and native configure support, and the NEWS entries for > the new target and native configurations. > > gdb/ > * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. > * NEWS: Mention new GNU/Linux RISC-V target. > * configure.host: Add riscv*-*-linux*. > * configure.nat: Add riscv*. > * configure.tgt: Add riscv*-*-linux*. I'm not sure if I can approve changes outside of riscv-* files, but if I could I'd approve these :) Thanks, Andrew > --- > gdb/Makefile.in | 4 ++++ > gdb/NEWS | 8 ++++++++ > gdb/configure.host | 2 ++ > gdb/configure.nat | 4 ++++ > gdb/configure.tgt | 6 ++++++ > 5 files changed, 24 insertions(+) > > diff --git a/gdb/Makefile.in b/gdb/Makefile.in > index 8c744d70c0..280b3b1283 100644 > --- a/gdb/Makefile.in > +++ b/gdb/Makefile.in > @@ -752,6 +752,8 @@ ALL_TARGET_OBS = \ > ppc-sysv-tdep.o \ > ppc64-tdep.o \ > ravenscar-thread.o \ > + riscv-linux-nat.o \ > + riscv-linux-tdep.o \ > riscv-tdep.o \ > rl78-tdep.o \ > rs6000-aix-tdep.o \ > @@ -2300,6 +2302,8 @@ ALLDEPFILES = \ > procfs.c \ > ravenscar-thread.c \ > remote-sim.c \ > + riscv-linux-nat.c \ > + riscv-linux-tdep.c \ > riscv-tdep.c \ > rl78-tdep.c \ > rs6000-lynx178-tdep.c \ > diff --git a/gdb/NEWS b/gdb/NEWS > index 669ed2d0eb..62cde1cde2 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -38,6 +38,14 @@ thread apply [all | COUNT | -COUNT] [FLAG]... COMMAND > FLAG arguments allow to control what output to produce and how to handle > errors raised when applying COMMAND to a thread. > > +* New native configurations > + > +GNU/Linux/RISC-V riscv*-*-linux* > + > +* New targets > + > +GNU/Linux/RISC-V riscv*-*-linux* > + > *** Changes in GDB 8.2 > > * The 'set disassembler-options' command now supports specifying options > diff --git a/gdb/configure.host b/gdb/configure.host > index 6bcb8da74c..23a2f16399 100644 > --- a/gdb/configure.host > +++ b/gdb/configure.host > @@ -149,6 +149,8 @@ powerpc64*-*-linux*) gdb_host=ppc64-linux > ;; > powerpc*-*-linux*) gdb_host=linux ;; > > +riscv*-*-linux*) gdb_host=linux ;; > + > s390*-*-linux*) gdb_host=linux ;; > > sh*-*-netbsdelf* | sh*-*-knetbsd*-gnu) > diff --git a/gdb/configure.nat b/gdb/configure.nat > index 7611266d86..feddeaa5e0 100644 > --- a/gdb/configure.nat > +++ b/gdb/configure.nat > @@ -267,6 +267,10 @@ case ${gdb_host} in > # Host: PowerPC, running Linux > NATDEPFILES="${NATDEPFILES} ppc-linux-nat.o ppc-linux.o" > ;; > + riscv*) > + # Host: RISC-V, running Linux > + NATDEPFILES="${NATDEPFILES} riscv-linux-nat.o" > + ;; > s390) > # Host: S390, running Linux > NATDEPFILES="${NATDEPFILES} s390-linux-nat.o" > diff --git a/gdb/configure.tgt b/gdb/configure.tgt > index f197160896..5e3bd5de71 100644 > --- a/gdb/configure.tgt > +++ b/gdb/configure.tgt > @@ -517,6 +517,12 @@ s390*-*-linux*) > build_gdbserver=yes > ;; > > +riscv*-*-linux*) > + # Target: Linux/RISC-V > + gdb_target_obs="riscv-linux-tdep.o riscv-tdep.o glibc-tdep.o \ > + linux-tdep.o solib-svr4.o symfile-mem.o linux-record.o" > + ;; > + > riscv*-*-*) > # Target: RISC-V architecture > gdb_target_obs="riscv-tdep.o" > -- > 2.17.1 >
>>>>> "Jim" == Jim Wilson <jimw@sifive.com> writes:
Jim> * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c.
This doesn't mention the ALL_TARGET_OBS change.
Jim> * NEWS: Mention new GNU/Linux RISC-V target.
Eli should review this bit.
Jim> * configure.host: Add riscv*-*-linux*.
Jim> * configure.nat: Add riscv*.
Jim> * configure.tgt: Add riscv*-*-linux*.
These parts are ok.
Jim> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
Jim> index 8c744d70c0..280b3b1283 100644
Jim> --- a/gdb/Makefile.in
Jim> +++ b/gdb/Makefile.in
Jim> @@ -752,6 +752,8 @@ ALL_TARGET_OBS = \
Jim> ppc-sysv-tdep.o \
Jim> ppc64-tdep.o \
Jim> ravenscar-thread.o \
Jim> + riscv-linux-nat.o \
Jim> + riscv-linux-tdep.o \
Jim> riscv-tdep.o \
Jim> rl78-tdep.o \
Jim> rs6000-aix-tdep.o \
I think only the tdep file should be listed here.
ALL_TARGET_OBS is used when --enable-targets=all is given.
In this case, we would not want the riscv-linux-nat.o object to be
linked in, since we're not necessarily building on linux.
Is riscv a 64-bit architecture? (I don't know.) If so, gdb still
splits 64-bit targets into a separate variable, I think in case one is
building on a 32-bit machine without a 64-bit integer type (or maybe if
you didn't want to use the extra memory to inflate a bunch of type
sizes, not sure). In this case you'd want to add the tdep file to
ALL_64_TARGET_OBS instead.
I wonder if this 32/64 bit thing is needed any more.
Tom
> From: Tom Tromey <tom@tromey.com> > Cc: gdb-patches@sourceware.org > Date: Wed, 08 Aug 2018 11:29:26 -0600 > > >>>>> "Jim" == Jim Wilson <jimw@sifive.com> writes: > > Jim> * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. > > This doesn't mention the ALL_TARGET_OBS change. > > Jim> * NEWS: Mention new GNU/Linux RISC-V target. > > Eli should review this bit. Sorry, missed that. It's okay. Thanks.
On Wed, 08 Aug 2018 10:29:26 PDT (-0700), tom@tromey.com wrote: >>>>>> "Jim" == Jim Wilson <jimw@sifive.com> writes: > > Jim> * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. > > This doesn't mention the ALL_TARGET_OBS change. > > Jim> * NEWS: Mention new GNU/Linux RISC-V target. > > Eli should review this bit. > > Jim> * configure.host: Add riscv*-*-linux*. > Jim> * configure.nat: Add riscv*. > Jim> * configure.tgt: Add riscv*-*-linux*. > > These parts are ok. > > Jim> diff --git a/gdb/Makefile.in b/gdb/Makefile.in > Jim> index 8c744d70c0..280b3b1283 100644 > Jim> --- a/gdb/Makefile.in > Jim> +++ b/gdb/Makefile.in > Jim> @@ -752,6 +752,8 @@ ALL_TARGET_OBS = \ > Jim> ppc-sysv-tdep.o \ > Jim> ppc64-tdep.o \ > Jim> ravenscar-thread.o \ > Jim> + riscv-linux-nat.o \ > Jim> + riscv-linux-tdep.o \ > Jim> riscv-tdep.o \ > Jim> rl78-tdep.o \ > Jim> rs6000-aix-tdep.o \ > > I think only the tdep file should be listed here. > > ALL_TARGET_OBS is used when --enable-targets=all is given. > In this case, we would not want the riscv-linux-nat.o object to be > linked in, since we're not necessarily building on linux. > > Is riscv a 64-bit architecture? (I don't know.) If so, gdb still > splits 64-bit targets into a separate variable, I think in case one is > building on a 32-bit machine without a 64-bit integer type (or maybe if > you didn't want to use the extra memory to inflate a bunch of type > sizes, not sure). In this case you'd want to add the tdep file to > ALL_64_TARGET_OBS instead. RISC-V is actually a family of ISAs, not one specific ISA. There are 4 base ISAs: rv32e (16 32-bit registers), rv32i (32 32-bit registers), rv64i (32 64-bit registers), and rv128i (32 128-bit revisers). They all look very similar and we developed the ports together, so they share the vast majority of the source. Since they're so similar we try to make sure that the various toolchain components always support all of them (aside from rv128i, which nobody has started serious work on and is only a placeholder in the spec). To enable this support in BFD we decided to put both the 32-bit and 64-bit RISC-V targets in the list of 32-bit targets. This allows toolchains configured with the 32-bit tuples to generate code for the 64-bit targets, which when coupled with multilib gives you a functioning setup. I'd like to keep this behavior in GDB if possible, so "riscv32-unknown-elf-gdb" can debug rv64i-based targets. One of my goals is to rely as little as possible on the tuple so users don't have to go find and build a whole bunch of them -- whenever I'm a user I find that to be a pain. > I wonder if this 32/64 bit thing is needed any more. Part of our rationale for doing this was that if you can build GCC 7 (the first version we support), then your host probably has support for 64-bit integer types. Nobody else has seemed to notice yet, but there also aren't that many RISC-V users so we're far from a representative sample.
>>>>> "Palmer" == Palmer Dabbelt <palmer@sifive.com> writes:
Palmer> To enable this support in BFD we decided to put both the 32-bit and 64-bit
Palmer> RISC-V targets in the list of 32-bit targets. This allows toolchains
Palmer> configured with the 32-bit tuples to generate code for the 64-bit targets,
Palmer> which when coupled with multilib gives you a functioning setup.
Palmer> I'd like to keep this behavior in GDB if possible, so "riscv32-unknown-elf-gdb"
Palmer> can debug rv64i-based targets.
My main concern is really whether --disable-64-bit-bfd still works.
I don't know if people still use this, but as long as it exists it seems
like it should continue to work. If RISC-V works in this setup, then it
is totally fine by me for gdb to follow, assuming it works as well.
Maybe to really test it has to be a 32 bit build with
--disable-64-bit-bfd and --enable-targets=all.
Tom
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
Tom> If RISC-V works in this setup, then it is totally fine by me for
Tom> gdb to follow, assuming it works as well.
That didn't come out quite like I intended. I meant to say, if BFD
works in this setup, etc.
Tom
On Wed, Aug 8, 2018 at 10:29 AM, Tom Tromey <tom@tromey.com> wrote: >>>>>> "Jim" == Jim Wilson <jimw@sifive.com> writes: > > Jim> * Makefile.in (ALLDEPFILES): Add riscv-linux-nat.c, riscv-linux-tdep.c. > > This doesn't mention the ALL_TARGET_OBS change. This is something I noticed was missing at the last minute and managed to screwed it up when i tried to fix it. I added the missing ChangeLog entry. > Jim> ravenscar-thread.o \ > Jim> + riscv-linux-nat.o \ > Jim> + riscv-linux-tdep.o \ > Jim> riscv-tdep.o \ > Jim> rl78-tdep.o \ > Jim> rs6000-aix-tdep.o \ > > I think only the tdep file should be listed here. Yes. I removed the riscv-linux-nat.o file from this list. > Is riscv a 64-bit architecture? (I don't know.) If so, gdb still > splits 64-bit targets into a separate variable, I think in case one is > building on a 32-bit machine without a 64-bit integer type (or maybe if > you didn't want to use the extra memory to inflate a bunch of type > sizes, not sure). In this case you'd want to add the tdep file to > ALL_64_TARGET_OBS instead. > > I wonder if this 32/64 bit thing is needed any more. To add to what Palmer said, the current riscv port is intended to support both 32-bit and 64-bit. It checks a hardware register or the ELF header flags to get the word size, and then things like register sizes are based on the word size. However, I only have access to a working 64-bit linux port, so the 32-bit linux support has not been tested yet. 32-bit glibc support was just recently submitted upstream, and we are hoping to get that resolved in time for the next glibc release early next year. The 32-bit linux kernel was booting but not running init last I heard, so that needs some bug fixing too. Once 32-bit linux support is sorted out I will start testing the gdb support for that. I am currently testing 32-bit linux binutils and gcc support using a user-mode qemu and some old glibc sources, but I don't think that I can do any useful gdb testing that way. While we have support for both 32-bit and 64-bit in theory, we can probably only support one target at the time, as this gets computed early and I don't think that we support changes to it. I think I'd have to define two targets, and have two sets of initialization functions, etc. This is something I can't easily do when I don't have access to the 32-bit linux target for testing yet. We also don't have any support for running 32-bit code on 64-bit systems yet, so this would be an issue only for cross gdb, and we don't have gdbserver yet so cross gdb isn't actually very useful at this time. So this all ends up being a moot question at the current time. Only the riscv64 linux gdb support is usable today. I have an ARM v7 chromebook with crouton Ubuntu chroot environment that I can use for 32-bit builds. I can try a build with --disable-64-bit-bfd and see what happens. This could take a little time, it is a slow machine, and I'll have to get the machine set up for builds again. Jim
> From: Tom Tromey <tom@tromey.com> > Cc: tom@tromey.com, Jim Wilson <jimw@sifive.com>, gdb-patches@sourceware.org > Date: Wed, 08 Aug 2018 17:25:59 -0600 > > My main concern is really whether --disable-64-bit-bfd still works. > I don't know if people still use this, but as long as it exists it seems > like it should continue to work. If RISC-V works in this setup, then it > is totally fine by me for gdb to follow, assuming it works as well. > > Maybe to really test it has to be a 32 bit build with > --disable-64-bit-bfd and --enable-targets=all. Btw, can you or someone else explain what exactly does "--enable-64-bit-bfd" do and what practical effects should it have on GDB? I frequently wonder whether I want that switch when building GDB, and I still don't know the answer. Thanks.
On Wed, Aug 8, 2018 at 7:36 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Tom Tromey <tom@tromey.com> >> Cc: tom@tromey.com, Jim Wilson <jimw@sifive.com>, gdb-patches@sourceware.org >> Date: Wed, 08 Aug 2018 17:25:59 -0600 >> >> My main concern is really whether --disable-64-bit-bfd still works. >> I don't know if people still use this, but as long as it exists it seems >> like it should continue to work. If RISC-V works in this setup, then it >> is totally fine by me for gdb to follow, assuming it works as well. >> >> Maybe to really test it has to be a 32 bit build with >> --disable-64-bit-bfd and --enable-targets=all. > > Btw, can you or someone else explain what exactly does > "--enable-64-bit-bfd" do and what practical effects should it have on > GDB? I frequently wonder whether I want that switch when building > GDB, and I still don't know the answer. Since I'm looking at this at the moment... BFD will automatically enable 64-bit support if you configure on a host with 64-bit support, or configure for a target with 64-bit support. It will also enable 64-bit support if you use --enable-64-bit-bfd. 64-bit support means you can use 64-bit integer types such as long long on a 32-bit host or long on a 64-bit LP64 host. If 64-bit support is enabled, and your compiler doesn't support it, then you get a configure error. If you use --disable-64-bit-bfd, then bfd will disallow use of 64-bit integer types. If you configure for a 64-bit target, you will get a configure error. As a practical matter, I think --enable/disable-64-bit-bfd doesn't really do anything useful unless you are configuring with --enable-targets=all. In this case, 64-bit targets will be enabled by default, and will fail to build on a 32-bit host with a compiler that doesn't support long long. You can work around that problem by using --disable-64-bit-bfd which will get you all of the 32-bit targets, and none of the 64-bit targets, which will allow the build to complete. Of course, nowadays, finding a 32-bit compiler without long long support would be hard, so this option combination is unlikely to be useful to anyone. I've been looking at the riscv{32,64} bfd support. Since configuring for riscv32 enables riscv64 support also, and riscv64 requires 64-bit support, this means that there is no riscv bfd support at all when using --disable-64-bit-bfd --enable-targets=all. It looks like the gdb riscv support is broken even without my patch, as we can't build a riscv32-elf gdb if we don't have bfd. I've got a build running to see if I can force a build failure. Jim
>>>>> "Jim" == Jim Wilson <jimw@sifive.com> writes:
Jim> I've been looking at the riscv{32,64} bfd support. Since configuring
Jim> for riscv32 enables riscv64 support also, and riscv64 requires 64-bit
Jim> support, this means that there is no riscv bfd support at all when
Jim> using --disable-64-bit-bfd --enable-targets=all. It looks like the
Jim> gdb riscv support is broken even without my patch, as we can't build a
Jim> riscv32-elf gdb if we don't have bfd. I've got a build running to see
Jim> if I can force a build failure.
I just wanted to reiterate that I don't know how important any of this
really is. The option exists, but I don't know if anybody relies on it.
Perhaps it could be removed instead. Maybe a question for the binutils
list as well.
Tom
On Aug 08 2018, Jim Wilson <jimw@sifive.com> wrote: > I've been looking at the riscv{32,64} bfd support. Since configuring > for riscv32 enables riscv64 support also, and riscv64 requires 64-bit > support, this means that there is no riscv bfd support at all when > using --disable-64-bit-bfd --enable-targets=all. Isn't that enforced by want64 in bfd/config.bfd? Andreas.
> From: Jim Wilson <jimw@sifive.com> > Date: Wed, 8 Aug 2018 20:43:20 -0700 > Cc: Tom Tromey <tom@tromey.com>, Palmer Dabbelt <palmer@sifive.com>, gdb-patches@sourceware.org > > Since I'm looking at this at the moment... > > BFD will automatically enable 64-bit support if you configure on a > host with 64-bit support, or configure for a target with 64-bit > support. It will also enable 64-bit support if you use > --enable-64-bit-bfd. 64-bit support means you can use 64-bit integer > types such as long long on a 32-bit host or long on a 64-bit LP64 > host. If 64-bit support is enabled, and your compiler doesn't support > it, then you get a configure error. > > If you use --disable-64-bit-bfd, then bfd will disallow use of 64-bit > integer types. If you configure for a 64-bit target, you will get a > configure error. > > As a practical matter, I think --enable/disable-64-bit-bfd doesn't > really do anything useful unless you are configuring with > --enable-targets=all. In this case, 64-bit targets will be enabled by > default, and will fail to build on a 32-bit host with a compiler that > doesn't support long long. Thanks. So you are saying that building on a 64-bit hosts will enable this by default, while a 32-bit build with --enable-64-bit-bfd only makes sense if --enable-targets=all is also used, is that right?
On Thu, Aug 9, 2018 at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote: > Thanks. So you are saying that building on a 64-bit hosts will enable > this by default, while a 32-bit build with --enable-64-bit-bfd only > makes sense if --enable-targets=all is also used, is that right? I didn't actually test that, but trying it, yes, this is how it works. If I'm on a 32-bit host, and use --enable-targets=all, I only get 32-bit targets enabled. If I'm on a 32-bit host and use --enable-targets=all --enable-64-bit-bfd then I get both 32-bit and 64-bit targets enabled. This requires that the C/C++ compiler supports long long. FYI for my riscv build experiment, with an unpatched gdb i.e. only the riscv bare metal support, a 32-bit hosted --enable-targets=all gdb does build and run. There is no bfd elf riscv support, only the bfd cpu-riscv.o file was built. The gdb riscv-tdep.o file was built and linked in. But without the bfd support I can't trigger it, so it appears to be harmless dead code. If I load a riscv32-elf binary, info target just says elf32-little, and disassembling code gives me ARM v7 instructions, which must be the default if it can't recognize an object file. I think that there can only be a problem if a gdb target port is making direct calls into the bfd target elf support, in which case that target port would have to be in the 64-bit object file list. The riscv linux port is not doing that currently, and I'm not sure if it ever would need to. But I can try another build after I get my riscv linux patches all checked in. Jim
diff --git a/gdb/Makefile.in b/gdb/Makefile.in index 8c744d70c0..280b3b1283 100644 --- a/gdb/Makefile.in +++ b/gdb/Makefile.in @@ -752,6 +752,8 @@ ALL_TARGET_OBS = \ ppc-sysv-tdep.o \ ppc64-tdep.o \ ravenscar-thread.o \ + riscv-linux-nat.o \ + riscv-linux-tdep.o \ riscv-tdep.o \ rl78-tdep.o \ rs6000-aix-tdep.o \ @@ -2300,6 +2302,8 @@ ALLDEPFILES = \ procfs.c \ ravenscar-thread.c \ remote-sim.c \ + riscv-linux-nat.c \ + riscv-linux-tdep.c \ riscv-tdep.c \ rl78-tdep.c \ rs6000-lynx178-tdep.c \ diff --git a/gdb/NEWS b/gdb/NEWS index 669ed2d0eb..62cde1cde2 100644 --- a/gdb/NEWS +++ b/gdb/NEWS @@ -38,6 +38,14 @@ thread apply [all | COUNT | -COUNT] [FLAG]... COMMAND FLAG arguments allow to control what output to produce and how to handle errors raised when applying COMMAND to a thread. +* New native configurations + +GNU/Linux/RISC-V riscv*-*-linux* + +* New targets + +GNU/Linux/RISC-V riscv*-*-linux* + *** Changes in GDB 8.2 * The 'set disassembler-options' command now supports specifying options diff --git a/gdb/configure.host b/gdb/configure.host index 6bcb8da74c..23a2f16399 100644 --- a/gdb/configure.host +++ b/gdb/configure.host @@ -149,6 +149,8 @@ powerpc64*-*-linux*) gdb_host=ppc64-linux ;; powerpc*-*-linux*) gdb_host=linux ;; +riscv*-*-linux*) gdb_host=linux ;; + s390*-*-linux*) gdb_host=linux ;; sh*-*-netbsdelf* | sh*-*-knetbsd*-gnu) diff --git a/gdb/configure.nat b/gdb/configure.nat index 7611266d86..feddeaa5e0 100644 --- a/gdb/configure.nat +++ b/gdb/configure.nat @@ -267,6 +267,10 @@ case ${gdb_host} in # Host: PowerPC, running Linux NATDEPFILES="${NATDEPFILES} ppc-linux-nat.o ppc-linux.o" ;; + riscv*) + # Host: RISC-V, running Linux + NATDEPFILES="${NATDEPFILES} riscv-linux-nat.o" + ;; s390) # Host: S390, running Linux NATDEPFILES="${NATDEPFILES} s390-linux-nat.o" diff --git a/gdb/configure.tgt b/gdb/configure.tgt index f197160896..5e3bd5de71 100644 --- a/gdb/configure.tgt +++ b/gdb/configure.tgt @@ -517,6 +517,12 @@ s390*-*-linux*) build_gdbserver=yes ;; +riscv*-*-linux*) + # Target: Linux/RISC-V + gdb_target_obs="riscv-linux-tdep.o riscv-tdep.o glibc-tdep.o \ + linux-tdep.o solib-svr4.o symfile-mem.o linux-record.o" + ;; + riscv*-*-*) # Target: RISC-V architecture gdb_target_obs="riscv-tdep.o"