The problems when building riscv-pk.

[xuyon...@gmail.com]

I want build riscv-pk to generate bbl,I use the following commands:

./configure --prefix=$RISCV --host=riscv64-unknow-linux-gnu

make

After execute make command,I encountered the following 2 problems:

/home/PKU/riscv/riscv-tools-installed/sysroot/usr/include/gnu/stubs.h:17:11: fatal error: gnu/stubs-lp64.h: No such file or directory

 # include <gnu/stubs-lp64.h>

           ^~~~~~~~~~~~~~~~~~

compilation terminated.

And 

riscv64-unknown-elf-gcc -nostartfiles -nostdlib -static  -o dummy_payload dummy_payload.o -L.  -ldummy_payload -lgcc -T ./dummy_payload/dummy_payload.lds

/home/ubuntu/riscv/riscv-tools-installed/bin/../lib/gcc/riscv64-unknown-elf/7.2.0/../../../../riscv64-unknown-elf/bin/ld: cannot open output file dummy_payload: Is a directory

collect2: error: ld returned 1 exit status

make: *** [dummy_payload] Error 1

What's the reason of the above 2 problems,and how to solve?I would appreciate any help/pointers.

Thanks!

Xu

[Jim Wilson]

On Thu, Sep 13, 2018 at 11:52 PM <xuyon...@gmail.com> wrote:
> I want build riscv-pk to generate bbl,I use the following commands:
> ./configure --prefix=$RISCV --host=riscv64-unknow-linux-gnu
> make
> After execute make command,I encountered the following 2 problems:
> /home/PKU/riscv/riscv-tools-installed/sysroot/usr/include/gnu/stubs.h:17:11: fatal error: gnu/stubs-lp64.h: No such file or directory
> # include <gnu/stubs-lp64.h>
> ^~~~~~~~~~~~~~~~~~
> compilation terminated.

That happens when you use -mabi=lp64 with a linux toolchain that was
not configured with direct support for -mabi=lp64. You probably have
a non-multilibbed lp64d toolchain. You either need to configure a
toolchain with lp64 support, or build a multilib toolchain that
supports lp64 and the default lp64d.

It looks like you are using a compiler from riscv-tools. This is an
old obsolete broken toolchain which is not ABI compatible with the
current toolchain. I would recommend using riscv-gnu-toolchain
instead.

It looks like you didn't give all info necessary to reproduce the
problem, as I don't believe that riscv-pk uses -mabi=lp64. I think
that there was a recent change to the linux kernel to start using it
though, to avoid accidentally generating FP instructions in kernel
code.

Jim

[Michael Clark]

On 15/09/2018, at 3:50 AM, Jim Wilson <ji...@sifive.com> wrote:

On Thu, Sep 13, 2018 at 11:52 PM <xuyon...@gmail.com> wrote:

I want build riscv-pk to generate bbl,I use the following commands:

./configure --prefix=$RISCV --host=riscv64-unknow-linux-gnu

make

After execute make command,I encountered the following 2 problems:

/home/PKU/riscv/riscv-tools-installed/sysroot/usr/include/gnu/stubs.h:17:11: fatal error: gnu/stubs-lp64.h: No such file or directory

# include <gnu/stubs-lp64.h>

          ^~~~~~~~~~~~~~~~~~

compilation terminated.

That happens when you use -mabi=lp64 with a linux toolchain that was
not configured with direct support for -mabi=lp64.  You probably have
a non-multilibbed lp64d toolchain.  You either need to configure a
toolchain with lp64 support, or build a multilib toolchain that
supports lp64 and the default lp64d.

It looks like you are using a compiler from riscv-tools.  This is an
old obsolete broken toolchain which is not ABI compatible with the
current toolchain.  I would recommend using riscv-gnu-toolchain
instead.

We should fix riscv-tools. Many folk are using this repo. I guess we’ll have to see if anything else breaks with a tools bump.

It looks like you didn't give all info necessary to reproduce the
problem, as I don't believe that riscv-pk uses -mabi=lp64.  I think
that there was a recent change to the linux kernel to start using it
though, to avoid accidentally generating FP instructions in kernel
code.

Interesting. Accidental FP instructions by mistake. Curious how Linux avoids this on x86... Oh okay. They are using the one ABI and suppress any extensions that generate float instructions. This would be equivalent to using -march=rv32imac or -march=rv64imac?

https://github.com/torvalds/linux/blob/master/arch/x86/Makefile#L60-L61

https://github.com/torvalds/linux/blob/master/arch/x86/Makefile#L104-L106

-march=rv32imac and -march=rv64imac is what I do in the bare metal test repo I was mentioning; that currently works with both compilers; but we need to add non-multilib to our test matrix.

I also believe bbl extracts a flat binary so the ABI flags in the ELF are ignored. QEMU ignores them for sure. Disabling the float instructions is probably all that is necessary. The Linux stuff is mostly defensive against GCC doing things like emitting SSE when you to something that could be promoted to memcpy under your feet when you didn’t ask for it.

Nevertheless, the two answers I proposed were not completely wrong, although I was missing the knowledge of a potentially breaking change to defaults. BTW Here are the relevant lines from riscv-tools (that I based my answer on):

https://github.com/riscv/riscv-tools/blob/master/build.sh#L24

https://github.com/riscv/riscv-tools/blob/master/build.common#L38

We should think about making a PR to fix the directory name clash, and think about backwards compatibility for the other change.

The hardware folk still use riscv-tools, including Berkeley. It is indeed good to know. bbl wants to do avoid accidentally emitting  float instructions by mistake because it does softfloat emulation.

I have another test repo where I want to avoid generating float instructions, but I use the imac approach. We should make a note to add non-multilib tools to the test matrix, as that’s what riscv-tools builds, possibly historic or possibly due to build times. The other thing we have to remember is that riscv-tools is one of many downstream repos that depends on previous defaults.

Of course multilib likely helps here but that will increase the build time for riscv-tools substantially, and thus affect the hardware repos that use it, “in the wild” so to speak e.g. backwards compatibility land.

[Jim Wilson]

On Fri, Sep 14, 2018 at 10:14 AM Michael Clark <michae...@mac.com> wrote:
> We should fix riscv-tools. Many folk are using this repo. I guess we’ll have to see if anything else breaks with a tools bump.

I'm not willing to upgrade the compiler in riscv-tools, because I
don't have time to fix any problems that might cause. Major compiler
upgrades always cause problems. It is the people using the compiler
that should chose when and where the compiler gets upgraded. Forcing
compiler upgrades on people via riscv-tools is a mistake. I'd rather
remove the compiler from riscv-tools. But I can't do that either,
because there may be people depending on it, and hence removing the
compiler may break other things. Basically, I'm screwed no matter
what I do, so I do nothing.

> Interesting. Accidental FP instructions by mistake. Curious how Linux avoids this on x86... Oh okay. They are using the one ABI and suppress any extensions that generate float instructions. This would be equivalent to using -march=rv32imac or -march=rv64imac?

If you change the -march to exclude FP, then you also have to change
the -mabi to exclude FP. So this is basically the same thing as what
I mentioned. But yes, there is concern that the compiler register
allocator might use an FP register if it runs out of integer
registers. So the safe thing to do is to choose march/mabi that
exclude FP registers. I'm not sure about the details though. I don't
follow linux kernel development.

> The hardware folk still use riscv-tools, including Berkeley. It is indeed good to know. bbl wants to do avoid accidentally emitting float instructions by mistake because it does softfloat emulation.

I've been told that rocket-chip is being fixed to stop using
riscv-tools, because this is causing problems.

I'm not interesting in helping to maintain riscv-tools. I already
have more projects than I have time for. If someone else wants to
maintain riscv-tools, and do the compiler upgrade, and deal with the
problems that it will cause, then I'm fine with that.

Jim

[Sober Liu]

Hi, Jim
If riscv-tools is not that good as expected, how about sifive pre-built version:
https://www.sifive.com/products/tools/ for "SiFive GNU Embedded Toolchain v20180629" and openOCD?

Thanks.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVaYCdRmbsCO7THaUrGG%3DGD-AVExgkuB%2BweNW8QVwsyUidQ%40mail.gmail.com.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[Bruce Hoult]

That's the 'riscv-gnu-toolchain', which is maintained and what we use internally. Source code here:

https://github.com/sifive/riscv-gnu-toolchain/

On Sat, Sep 15, 2018 at 5:43 AM, Sober Liu <sob...@nvidia.com> wrote:

Hi, Jim
If riscv-tools is not that good as expected, how about sifive pre-built version:
https://www.sifive.com/products/tools/ for "SiFive GNU Embedded Toolchain v20180629" and openOCD?

Thanks.

-----Original Message-----
From: Jim Wilson <ji...@sifive.com>
Sent: Saturday, September 15, 2018 4:47 AM
To: Michael Clark <michae...@mac.com>
Cc: xuyon...@gmail.com; RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev] The problems when building riscv-pk.

On Fri, Sep 14, 2018 at 10:14 AM Michael Clark <michae...@mac.com> wrote:
> We should fix riscv-tools. Many folk are using this repo. I guess we’ll have to see if anything else breaks with a tools bump.

I'm not willing to upgrade the compiler in riscv-tools, because I don't have time to fix any problems that might cause.  Major compiler upgrades always cause problems.  It is the people using the compiler that should chose when and where the compiler gets upgraded.  Forcing compiler upgrades on people via riscv-tools is a mistake.  I'd rather remove the compiler from riscv-tools.  But I can't do that either, because there may be people depending on it, and hence removing the compiler may break other things.  Basically, I'm screwed no matter what I do, so I do nothing.

> Interesting. Accidental FP instructions by mistake. Curious how Linux avoids this on x86... Oh okay. They are using the one ABI and suppress any extensions that generate float instructions. This would be equivalent to using -march=rv32imac or -march=rv64imac?

If you change the -march to exclude FP, then you also have to change the -mabi to exclude FP.  So this is basically the same thing as what I mentioned.  But yes, there is concern that the compiler register allocator might use an FP register if it runs out of integer registers.  So the safe thing to do is to choose march/mabi that exclude FP registers.  I'm not sure about the details though.  I don't follow linux kernel development.

> The hardware folk still use riscv-tools, including Berkeley. It is indeed good to know. bbl wants to do avoid accidentally emitting  float instructions by mistake because it does softfloat emulation.

I've been told that rocket-chip is being fixed to stop using riscv-tools, because this is causing problems.

I'm not interesting in helping to maintain riscv-tools.  I already have more projects than I have time for.  If someone else wants to maintain riscv-tools, and do the compiler upgrade, and deal with the problems that it will cause, then I'm fine with that.

Jim

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVaYCdRmbsCO7THaUrGG%3DGD-AVExgkuB%2BweNW8QVwsyUidQ%40mail.gmail.com.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CY4PR12MB1221768C9BED44077E91DD6EAD180%40CY4PR12MB1221.namprd12.prod.outlook.com.

[Jim Wilson]

On Sat, Sep 15, 2018 at 10:42 AM Bruce Hoult <bruce...@sifive.com> wrote:
> That's the 'riscv-gnu-toolchain', which is maintained and what we use internally. Source code here:
> https://github.com/sifive/riscv-gnu-toolchain/

I would suggest riscv/riscv-gnu-toolchain instead which is the master
tree. sifive/riscv-gnu-toolchain is a fork of that to hold the
proposed clic (core local interrupt controller) support and is not as
actively maintained.

Otherwise, the riscv gnu toolchain is the same as any other cpu gnu
toolchain. You can get sources from upstream, FSF
binutils/gcc/glibc/gdb and sourceware newlib. Or if you have a recent
linux distro you can just install a package and get a riscv-linux
compiler. Or you can grab a copy of
debian/fedora/opensuse/freebsd/etc and get a system you can boot on
qemu. Or you can look at OpenEmbedded and build your own system from
scratch. Or you can use github sifive/freedom-u-sdk to build a
kernel+buildroot to boot on qemu. Or you can use crosstools-ng to
build a compiler, a patch for riscv64-linux support was just submitted
yesterday, but it already has embedded riscv support. Etc.

And of course you can find LLVM at llvm.org, though the LLVM support
is not as complete as the GCC support as yet.

Jim

[Michael Clark]

This belies the fact that there is an integration problem. It is a management problem pure and simple. I personally don’t think the problem can be very easily solved as a riscv-qemu maintainer. All I can do is to make as few backwards incompatible changes as possible. i.e. think carefully about how a change will impact users, and the consequences of a particular approach (like following arm’s SOC struct model in QEMU, which is static parameterizarion vs a dynamic parameterization model that matches the multitude of configurations from rocket-chip or any other core).

It is pointless to propose any solutions when maintainers don’t want to adopt them. CI systems (I is for Integration) use git repos to continuously integrate related components. They use web-hooks to archive sources, cache build artefacts, upload binaries, and record test results of working combinations. They use git repos.

Linux distros and cross tools use patches and tarballs. They are distinct and completely separate problems. One must not confuse downstream distributors and upstream developers whose maintainer branches are in the RISC-V GitHub organisation.

The diaspora is great, but it springs from github.com/riscv and that has a set of git repos that are in sore need of automated cross module integration tests. Once that is present, the risk of changes reduces.

[Tommy Murphy]

On Saturday, 15 September 2018 21:02:46 UTC+1, Jim Wilson wrote:

Or you can use crosstools-ng to
build a compiler, a patch for riscv64-linux support was just submitted
yesterday, but it already has embedded riscv support.   Etc.

Hi Jim - I just followed the crosstools-NG instructions (https://crosstool-ng.github.io/docs/) for installing. building and running it but when I run ct-ng menuconfig there's no mention of RISC-V In the Target options > Target Architecture section.

Am I doing something wrong?

Should I be looking somewhere else other than the crosstools-NG master repo?

Thanks a lot.

P.S. Thanks for your posts on another thread which I intend to respond to.

 

[Tommy Murphy]

Sorry - ignore that - I had failed to enable Paths and misc options > Try features marked as EXPERIMENTAL

When I did then riscv appeared.

Apologies for wasting your time.