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

[Jim Wilson <jimw@sifive.com>]

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