RISCV GNU toolchain configuration error

[나태식]

Hi,
I'm trying to install RISCV toolchain on another machine and having difficulty in installing.
I installed successfully for riscv-fesvr, riscv-isa-sim, but not for riscv-gnu-toolchain.

My gcc version is 4.8.5 and I've checked GMP, MPFR, MPC version.
It seems like there is nothing wrong with the version, but I was not able to figure it out what the problem is.
Here are some several outputs I can get.

> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)

> rpm -qa | grep gmp
gmp-devel-6.0.0-12.el7_1.x86_64
gmp-6.0.0-12.el7_1.x86_64
> rpm -qa | grep mpfr
mpfr-3.1.1-4.el7.x86_64
mpfr-devel-3.1.1-4.el7.x86_64
> rpm -qa | grep mpc
libmpcdec-1.2.6-12.el7.x86_64
libmpc-1.0.1-3.el7.x86_64


> cd rocket-chip/riscv-tools
> ./build.sh
Starting RISC-V Toolchain build process

Removing existing riscv-gnu-toolchain/build directory
Configuring project riscv-gnu-toolchain
Building project riscv-gnu-toolchain
econflicts: 1 shift/reduce
In file included from /nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/binutils/syslex_wrap.c:25:0:
syslex.c: In function 'yy_scan_bytes':
syslex.c:1681:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for ( i = 0; i < _yybytes_len; ++i )
                 ^
conflicts: 27 shift/reduce
conflicts: 58 shift/reduce, 10 reduce/reduce
conflicts: 1 shift/reduce
arlex.c: In function 'yy_scan_bytes':
arlex.c:1803:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for ( i = 0; i < _yybytes_len; ++i )
                 ^
conflicts: 76 shift/reduce
In file included from /nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/ld/ldlex-wrapper.c:26:0:
ldlex.c: In function 'yy_scan_bytes':
ldlex.c:3952:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for ( i = 0; i < _yybytes_len; ++i )
                 ^
configure: WARNING: decimal float is not supported for this target, ignored
/nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/configure: line 13590: SIM_AC_OPTION_HOSTENDIAN: command not found
configure: WARNING: libipt is missing or unusable; some features may be unavailable.
configure: WARNING: babeltrace is missing or unusable; GDB is unable to read CTF data.
/nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../common/sim-profile.c: In function 'profile_pc_init':
/nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../common/sim-profile.c:566:4: warning: left shift count >= width of type [enabled by default]
    ((1 << sizeof (sim_cia) * (8 - 1))
    ^
/nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../common/sim-profile.c:585:3: warning: left shift count >= width of type [enabled by default]
   bucket_size = ((1 << ((sizeof (sim_cia) * 8) - 1))
   ^
Creating observer.htmp
Creating observer.itmp
conflicts: 39 shift/reduce, 53 reduce/reduce
conflicts: 34 shift/reduce
/nethome/tna6/work/openhw/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/gdb/m2-exp.y:301.25-44: warning: rule useless in parser due to conflicts: $@2: /* empty */
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.
gmake: *** [stamps/build-gcc-newlib] Error 1

---------------------------------------
I really appreciate if you could help me to figure it out.
Many thanks in advance!!

[Stefan O'Rear]

On Fri, Jan 27, 2017 at 3:24 PM, 나태식 <tscha...@gmail.com> wrote:
> My gcc version is 4.8.5 and I've checked GMP, MPFR, MPC version.
> It seems like there is nothing wrong with the version, but I was not able to
> figure it out what the problem is.
> Here are some several outputs I can get.

>> rpm -qa | grep mpc
> libmpcdec-1.2.6-12.el7.x86_64
> libmpc-1.0.1-3.el7.x86_64
>

missing libmpc-devel?

-s

[Tommy Murphy]

Have you tried this?

cd riscv-gcc
contrib/download-prerequisites
cd ..
./build.sh

[Tommy Murphy]

Also - is gcc 4.8.5 recent enough to build the RISC-V tools?

[나태식]

I have no root privilege on this machine.

so I might need to ask the manager to install libmpc-devel and check all the dependencies.

As i know RISC-V tools need gcc version higher than 4.8

I'll let you know once I've tried install all the dependencies first.

Thank you guys for the valuable comments.

[Paulo Matos]

On 28/01/17 15:22, 나태식 wrote:
> I have no root privilege on this machine.
> so I might need to ask the manager to install libmpc-devel and check all
> the dependencies.
> As i know RISC-V tools need gcc version higher than 4.8
> I'll let you know once I've tried install all the dependencies first.
> Thank you guys for the valuable comments.
>
>

Hi, you don't need root permissions. The gmp, mpfr and mpc deps can be
fulfilled by downloading the source code for this and unzipping them
inside the gcc folder. As far as I can remember gcc will look for these
and build them if necessary.

Paulo

> On Saturday, January 28, 2017 at 7:11:56 AM UTC-5, Tommy Murphy wrote:
>
> Also - is gcc 4.8.5 recent enough to build the RISC-V tools?
>

> --
> 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
> <mailto:sw-dev+un...@groups.riscv.org>.
> To post to this group, send email to sw-...@groups.riscv.org
> <mailto: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/235ec0b8-739f-455b-a575-e736ad3d3d2b%40groups.riscv.org
> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/235ec0b8-739f-455b-a575-e736ad3d3d2b%40groups.riscv.org?utm_medium=email&utm_source=footer>.

--
Paulo Matos

[Tommy Murphy]

That's what running download_prerequisites as I mentioned above should do.

[Tommy Murphy]

Also, using download_prerequisites to build local versions of a few libs can help to produce tools that run on a wider range of linuxes including those where some of those libs are not available from the standard repos (eg CentOS/RHEL 6 if I recall correctly).

[나태식]

After having installed libmpc-devel, it works fine.
Thanks!!
I tried to install local gcc with mpfr, mpc, and gmp installed separately, but, I was not able to install the tool chain with some errors.
And I didn't know that I can download the libraries using download_prerequisites.
Anyway thank you all for your valuable comments.

Just a comment, when building tool chain, current directory (.) should not be in the $PATH variable.
I just wanted to share this for those who may have difficulties in installing the tool chain.
Thanks you everyone!!!

[Tommy Murphy]

Building the newlib bare metal toolchain has always worked for me without setting ANY path beforehand even though some instructions say to do so. I think that may be necessary for building the Linux toolchain/kernel but not the newlib toolchain. Also as I said running contribute/download_requisites to build libmpc etc locally obviates the need for the relevant development packages and also makes the resulting toolchain build more portable.

[Vania Joloboff]

Hi

Regarding memory protection, the specs say (section 3.5)
that there is a hardware PMA-checker that checks
PMA's (physical memory attributes).

There are also XWR bits in the PTE's (page table entries).

Later (section 3.6) it mentions the existence of
a PMP (Physical Memory Protection) unit .
The PMP seems to be something different from the PMA-checker

Is there an example of such things somewhere ?
I have found nothing so far.
I don't really understand how the PMP, the PMA's
and the XRW bits in the PTE's are connected.
Where can I get info about that from a real
implementation to better understand the relationships ?

I suppose the XWR bits in the PTE's are constructed by
deducting information from the PMA's...

A complete example of Load/Store operation in
the documentation would help

--

Best Regards,

Vania Joloboff
INRIA Bretagne Atlantique
Campus de Beaulieu
35042 Rennes Cedex
Tél: +33 (0)2 9984 7100
Fax: +33 (0)2 9984 7171

[Samuel Falvo II]

On Mon, Feb 6, 2017 at 6:15 AM, Vania Joloboff <vania.j...@inria.fr> wrote:
> Is there an example of such things somewhere ?
> I have found nothing so far.

There are various examples, mostly on other architectures. However,
to show you just how platform dependent they are, I'll pick only a
handful of extremely divergent examples.

I start with the Commodore 128. Yes, a computer introduced in 1984
along-side the Commodore-Amiga 1000, had a very humble MMU of sorts
(the 8277 chip) that lay outside both of the computer's CPUs (Z-80 and
8502A). Both of these CPUs could access a maximum of 64KB of memory,
but the computer shipped with 128KB. With some clever hackery on the
part of the computer's owner, you could coax 256KB easily, and
sometimes up to 512KB if you're particularly desperate.

The MMU for this platform allowed the memory (as seen by the CPU
itself) to be split into several different regions, each of which
addressed different portions of physical address space, not entirely
dissimilar to paged MMUs do today. However, due to the unique
requirements of the 8502A CPU (a 6502 derivate), some special
accomodations had to be made to support zero-page, stack, and the
availability of ROM regardless of the current memory configuration.
That is to say, the MMU *guaranteed* (typically) 1KB of low memory and
1KB of high-memory referred to (so-called) "bank 0" memory, so that
software running in banks 1-3 can still invoke system calls.

(Sidebar: To the Commodore 128 software community, a "bank" is a 64KB
"page" of memory.)

Note that this counts as an example of PMP, because it's _external_ to
the CPUs themselves. You could easily pull the CPUs out and replace
them (and the system ROMs) with a RISC-V derivate and support
privilege modes and hardware-based page table walkers and the such,
and the 8277 MMU chip won't care if you're running in M-mode, S-mode,
or U-mode. If you map the top of physical memory to 16KB in your
local address space, then the top 1KB of that page will still refer to
bank 0, even if the other 3KB of the page are mapped to bank 1.

Another example comes from the Commodore-Amiga 1000 computer
(specifically). The computer shipped before system software ROMs
could be fabricated, so Commodore had to compromise to meet shipping
deadlines. A "256KB" RAM computer actually shipped with 512KB of RAM
total. Half of the RAM was mapped to where the ROMs *would* be once
they came out of the fabs. During cold-boot, the Amiga 1000 required
you to insert a "Kickstart" disk, which loaded the contents of high
RAM with an image of the Kickstart ROM. Once loaded, the Amiga
flipped a bit in GPIO which forced the WE# signal to that RAM to
remain negated (high). Even if you flipped the GPIO bit back, WE#
would remain high until the system was reset. In this way, RAM now
acted exactly like ROM.

Again, we're seeing circuitry which exists external to the CPU
intended to protect some invariant of physical memory from accidental
abuse by untrusted system software. (And since AmigaOS was a
single-address-space OS which could freely mix supervisor and
user-mode operation, effectively all software had to be treated as if
it were running in supervisor mode.) In this case, the PMP basically
consisted of a single D-flip-flop. It's a far cry simpler than the
8277 MMU in the C128, but it still counts!

> I don't really understand how the PMP, the PMA's
> and the XRW bits in the PTE's are connected.

RWX bits are used by the CPU to determine which pages your U-mode
software can access *before* the address is presented to the rest of
the memory subsystem.

(ASIDE: this may not actually be the case; some architectures
parallelize memory operations to a great extent. But, LOGICALLY, this
is the intent, and is a relevant abstraction for the topic.)

Once the CPU's MMU decides you have privileges to access a particular
page, it's translated to a "physical address". Let's call this a PA
so we make sure we're always talking about the same thing.
Post-translation, the CPU will attempt to reference memory using that
PA. Note that M-mode also works directly with PAs (no translation at
all!), so the question arises: if S-mode can map memory used by M-mode
(since they're both using PAs), how do you enforce complete isolation
between these two components?

Different PA ranges will have different aspects ascribed to them. As
an electrical engineer, I could decide PAs between $00000000 and
$003FFFFF refer to cached RAM. I could also say that memory from
$00800000-$00BFFFFF refers to the same memory but in an uncached
manner. Note that the system programmer doesn't get to make this
decision; this is an attribute of the physical hardware on which your
software is running. Typically, but not always, there are *no*
configuration registers that influences this design. Hence, "Physical
Memory Attribute" (PMA).

What determines whether or not I access a block of RAM in a cached
versus uncached way is a chunk of circuitry on the mainboard of the
computer. This circuitry is typically referred to as your "memory
controller." Since it's unlikely you'll ever want U-mode software to
reference memory in a way that bypasses caches, you can configure your
system software to use its page tables to prevent access to
$00800000-$00BFFFFF. So long as this is sufficient and you trust your
S-mode code implicitly, your memory controller can be oblivious and
get by just fine.

But, what happens when you no longer trust your software running in
S-mode? Consider most Linux and BSD installations allow developers
and users with root privileges to install kernel modules, post-boot
even. Can you continue to trust the system software under these
conditions? In a perfect world, the web of trust extends to those
with root privileges. However, in reality, root escalations seem
prominent enough that it's wise to not trust even root user to vet all
software that a system can run, particularly since she might not even
be *aware* of the software that's currently running.

Under these conditions, we need to export the most base security
requirements to the memory controller circuitry. We want to reduce
our trusted computing base to JUST the engineers responsible for the
system software (M-mode software) and the memory controller's design.
In this case, the memory controller needs to know just one piece of
additional information: is this memory access made on behalf of M-mode
or not? (Extra credit: not only check that M-mode is running, but
also check that the last fetched instruction came from a well-known
range of memory.) Given that one piece of information, the memory
controller itself is now capable of deciding whether or not to grant
uncached memory access to system software. If you're running in
M-mode, then access is granted unconditionally. Otherwise, the memory
controller might (conditionally, based on a configuration register
setting) issue a bus error, and prevent access. Like the Commodore
128's MMU above, this decision is made *external* to any and all CPUs,
and is intended to protect the memory from untrusted access. Hence,
the memory controller is now more than just a controller: it is now a
Physical Memory Protection unit.

Hope this helps clear the relationships and rationales up.

Fun fact: Commodore named the 8277 chip a "memory management unit"
because MMUs were all the rage during that time. It was a very
marketable name. Today, the 8277 would be called a PMP chip.

> I suppose the XWR bits in the PTE's are constructed by
> deducting information from the PMA's...

They're decided by supervisor software. This software is *trusted* to
have knowledge of PMAs, but is not guaranteed to do so. The PMP
exists to enforce the desired PMAs in complete isolation from the
trustworthiness of the system software.

--
Samuel A. Falvo II