[5/5] RISC-V: Add configure support riscv*-linux*.

  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(+)
  

* 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