[lowrisc-dev] Re: Question on lowrisc project

Michael Clark michaeljclark at mac.com
Sun Feb 7 22:10:35 GMT 2016


Hi Pawan, Wei,

I was thinking about testing dynamic libraries by spinning a root.bin
containing a dynamic libc.so

After reflection, I think we need to audit rtld.c

There are some known issues with symbol interposition. Dynamic linking
has different link time binding behavior than static linking. It's not
load time by default. It's actually lazy unless you set LD_BIND_NOW.
Also compile time results are not predictable. i.e. -static linking will
return duplicate symbol errors but -shared linking will happily proceed
(depends on tool-chain). I also believe the GOT (Global Offset Table) is
a writable segment used by the PLT (Procedure Linkage Table). The GOT
does not contain code, however it does contain information that can
dynamically effect control flow at run-time, after the initial linking
and loading of an executable into memory. The PLT stubs lazily call
_dl_runtime_resolve to defer filling in the blanks in the GOT. In
conclusion, the dynamic vs static link behavior is not consistent.
Someone should decide when we are ready to enable dynamic linking.
Perhaps not today. We need to prioritize. I was thinking a careful audit
of the dynamic linker is required.

I only need sys_read and sys_write so I am happy with how it is now:
"static".

BTW Have you looked at musl <http://www.musl-libc.org/>. It has an MIT
license, which is a BSD compatible license. i.e. is compatible with the
current RISC-V license.

Best Regards,
Michael.

On 7/2/16 5:32 pm, Pawan Reddy Sibbala wrote:
> Hello Wei,
>
> Thank you. I'm able to run binaries inside RISC-V linux now which are
> compiled/linked statically.
>
> Thanks and regards,
> Pawan
>
> On Mon, Feb 1, 2016 at 7:33 AM, Wei Song <ws327 at cam.ac.uk> wrote:
>
>> Hello Pawan,
>>
>> For compiling a program to run statically inside RISC-V Linux, you need to
>> add an argument "-static".
>> There is a make file in $TOP/riscv-tools/hello.
>> It generates three different executables for all environment.
>> hello.linux is the one running in RISC-V Linux.
>> May be you could have a look.
>>
>> best regards,
>> Wei
>>
>>
>> On 31/01/2016 22:30, Pawan Reddy Sibbala wrote:
>>
>> Hello Wei,
>>
>> Yes, the newly generated images work fine on the FPGA.
>>
>>       I suppose some busybox configuration options need to be enabled to
>> support these features and I did not have enough time to figure out.
>>       If in case you know how to do it, please let me know; therefore I
>> can update the configuration file.
>>
>>      The prepared configure file is used by the following command:
>>       http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/
>>       Build the root image (root.bin) for the Linux kernel
>>       cp $TOP/riscv-tools/busybox_config .config
>>
>>      You can use the busybox configuration mechanism to generate your own
>> configuration file.
>>      cd $TOP/riscv-tools/busybox-1.21.1
>>      make menuconfig
>>      But be careful you may need to manually change the cross-compiler to
>> riscv-gcc.
>>
>> I'm not quite sure how to do it now, but I'll definitely let you know if I
>> figure it out in the future.
>>
>>      As for why you cannot run your own programs. May be you would like to
>> show me the error messages?
>>      And perhaps the script you used to compile your programs as well. It
>> would be difficult for me to guess with a simple description of it does not
>> run.
>>      The common reasons would be wrong tool-chain or non-static
>> compilation.
>>      So any programs run inside the RISC-V Linux should be compiled using
>> the riscv-gcc and should be statically compiled/linked.
>>      There is no dynamic libraries in the RISC-V Linux. So if the
>> executable needs some run-time libraries, it probably would not run
>> properly.
>>      There are ways to support dynamic libraries in the RISC-V Linux, only
>> if you would like to be bothered with recompiling the libraries and
>> manually install                them into a clean kernel.
>>
>> The programs I'm trying are as simple as printing "hello world" and adding
>> two numbers.
>>
>> #include <stdio.h>
>> int main(void) {
>> printf("Hello World\n");
>> return 0;
>> }
>>
>> I'm generating the executable using the following command
>> $ riscv-linux-gcc -o hello hello.c.  Do I have to do anything different
>> for static linking ?
>>
>> Then, when I try to run the generated executable on linux booted on
>> rocket, I get "segmentation fault" error as shown below. I tried it with
>> few programs and I get the same error for all of them. However, when I
>> compile the program using the following command
>>
>> $ riscv64-unknown-elf-gcc -o hello hello.c
>>
>> and try to run the generated executable using front-end server and pk, it
>> runs without any issues.
>>
>>
>>
>> BusyBox v1.22.1 (2014-07-19 16:30:20 PDT) built-in shell (ash)
>>
>> Enter 'help' for a list of built-in commands.
>>
>> / # ls
>> bin                     home                    sbin
>>
>> bzip2_base.gcc43-64bit  lib                     tests
>>
>> dev                     lost+found              tmp
>>
>> etc                     proc                    usr
>>
>> / # cd home
>>
>> /home # ls
>>
>> ctests
>>
>> /home # cd ctests/
>>
>> /home/ctests # ls
>>
>> add          hello        hello.c~     userinput.c
>> add.c        hello.c      userinput
>>
>> /home/ctests # ./hello
>>
>> *Segmentation fault*
>>
>> I'm not sure what I'm missing to make the executables run on RISC-V linux
>> kernel as the precompiled executables are running fine.
>>
>> Thanks and regards,
>> Pawan
>>
>>
>>
>>
>> On Thu, Jan 28, 2016 at 5:38 AM, Wei Song <ws327 at cam.ac.uk> wrote:
>>
>>> Hello Pawan,
>>>
>>> Good to know now you can regenerate a RISC-V kernel and root.bin to run
>>> in Spike.
>>> I suppose if you try the newly generated images on FPGA, they should just
>>> work fine.
>>>
>>> Please keep the lowrisc mailist in cc as it would keep a record and
>>> someone else may have the same problem.
>>>
>>> For your further questions:
>>>
>>> After the boot, when I try to press arrow keys, it acts weird ( as seen
>>> above [[D^ etc ). One more difference I notice is, during the boot process
>>> for precompiled FPGA image provided, even these lines are executed and the
>>> command line doesnot act weird like in the above case. But, I am not able
>>> to execute the binaries I compile in either of them. Could you tell me what
>>> you think would be the problem?
>>>
>>>
>>> This is actually OK. The precompiled root.bin is the original copy from
>>> RISC-V (Berkeley team). They use a different busybox configuration which
>>> was not disclosed.
>>> I tried to make a similar configuration and this is probably the best I
>>> get.
>>> The problem for the weird characters is due to the lack of command
>>> history and auto-filling.
>>> This has no effect on executing programs.
>>> I suppose some busybox configuration options need to be enabled to
>>> support these features and I did not have enough time to figure out.
>>> If in case you know how to do it, please let me know; therefore I can
>>> update the configuration file.
>>>
>>> The prepared configure file is used by the following command:
>>> http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/
>>> Build the root image (root.bin) for the Linux kernel
>>> cp $TOP/riscv-tools/busybox_config .config
>>>
>>> You can use the busybox configuration mechanism to generate your own
>>> configuration file.
>>> cd $TOP/riscv-tools/busybox-1.21.1
>>> make menuconfig
>>> But be careful you may need to manually change the cross-compiler to
>>> riscv-gcc.
>>>
>>> As for why you cannot run your own programs. May be you would like to
>>> show me the error messages?
>>> And perhaps the script you used to compile your programs as well. It
>>> would be difficult for me to guess with a simple description of it does not
>>> run.
>>> The common reasons would be wrong tool-chain or non-static compilation.
>>> So any programs run inside the RISC-V Linux should be compiled using the
>>> riscv-gcc and should be statically compiled/linked.
>>> There is no dynamic libraries in the RISC-V Linux. So if the executable
>>> needs some run-time libraries, it probably would not run properly.
>>> There are ways to support dynamic libraries in the RISC-V Linux, only if
>>> you would like to be bothered with recompiling the libraries and manually
>>> install them into a clean kernel.
>>>
>>> 2.   The SPECint benchmarks which you ran on FPGA, are they with the
>>> help of proxy kernel ? I was wondering if you recorded the runtime of the
>>> benchmarks? The link provided talks about miss rates and memory traffic.
>>>
>>>
>>> Yes, I run them using the front-end server and pk (without Linux kernel).
>>> Not all cases can run in this way.
>>> For getting the runtime, you basically need some program to read the
>>> CSR.cycle before and after the execution.
>>> It is easier with pk since you can revise the pk or the front-end server
>>> code to do this.
>>> Run benchmark inside kernel is a little bit tricky.
>>> I am not sure how to do it. May be you can have a separate program to
>>> read time.
>>> Then you can revise the benchmark script to call this extra program to
>>> read time before and after each benchmark case.
>>> I had never tried this.
>>>
>>> For running the SPECInt benchmark, Christopher Celio has a good wrapper
>>> for it.
>>> https://github.com/ccelio/Speckle
>>> However, he must have updated the wrapper to work with the latest
>>> toolchain. If you are going to use this, you need to check out an old
>>> version.
>>> What I had used is commit 6b9b92cbff85  10-April-2015.
>>> I also needed to revise some of his scripts to make it work.
>>>
>>> Best regards,
>>> Wei
>>>
>>>
>>> On 28/01/2016 05:50, Pawan Reddy Sibbala wrote:
>>>
>>> Hello Wei,
>>>
>>> Right, I did not actually do the spike emulation the first time. Sorry
>>> about that. But, I did it now and the results are the same as yours. Please
>>> look at them below.
>>>
>>> $ gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
>>> Target: x86_64-linux-gnu
>>> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
>>>
>>> $ cd $TOP/riscv-tools
>>> $ git status
>>> HEAD detached at 722377f
>>>
>>> $ cd riscv-gcc
>>> $ git status
>>> On branch master
>>> Your branch is up-to-date with 'origin/master'.
>>>
>>> $ riscv-linux-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=riscv-linux-gcc
>>>
>>> COLLECT_LTO_WRAPPER=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv/libexec/gcc/riscv-linux/4.6.1/lto-wrapper
>>> Target: riscv-linux
>>> Configured with:
>>> /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gcc/gcc-4.6.1/configure
>>>  --target=riscv-linux
>>> --prefix=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv --enable-shared
>>>  --disable-threads --enable-tls --enable-languages=c,c++
>>> --disable-libmudflap --disable-libssp
>>>  --disable-libquadmath --disable-nls --disable-multilib
>>> --disable-bootstrap --with-headers=
>>>
>>>  /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gcc/linux-headers//include
>>> Thread model: single
>>> gcc version 4.6.1 (GCC)
>>>
>>> $ riscv64-unknown-elf-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=riscv64-unknown-elf-gcc
>>>
>>> COLLECT_LTO_WRAPPER=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv/libexec/gcc/riscv64-unknown-elf/4.9.2/lto-wrapper
>>> Target: riscv64-unknown-elf
>>> Configured with:
>>> /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gnu-toolchain/build/src/newlib-gcc
>>> /configure --target=riscv64-unknown-elf
>>> --prefix=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv
>>> --disable-shared --disable-threads --enable-tls --enable-languages=c,c++
>>> --with-newlib --disable-libmudflap
>>> --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls
>>> Thread model: single
>>> gcc version 4.9.2 (GCC)
>>>
>>> $TOP/riscv-tools
>>> $ spike +disk=./busybox-1.21.1/root.bin ./linux-3.14.13/vmlinux
>>>
>>> [    0.000000] Linux version 3.14.13-g989153f (siva at Siva-Ubuntu) (gcc
>>> version 4.6.1 (GCC) ) #1 Wed Jan 27 00:35:01 EST 2016
>>> [    0.000000] Detected 0x100000000 bytes of physical memory
>>> [    0.000000] Zone ranges:
>>> [    0.000000]   Normal   [mem 0x00000000-0x77ffffff]
>>> [    0.000000] Movable zone start for each node
>>> [    0.000000] Early memory node ranges
>>> [    0.000000]   node   0: [mem 0x00000000-0x77ffffff]
>>> [    0.000000] On node 0 totalpages: 245760
>>> [    0.000000] free_area_init_node: node 0, pgdat ffffffff80247ef8,
>>> node_mem_map ffffffff80290000
>>> [    0.000000]   Normal zone: 1680 pages used for memmap
>>> [    0.000000]   Normal zone: 0 pages reserved
>>> [    0.000000]   Normal zone: 245760 pages, LIFO batch:15
>>> [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>>> [    0.000000] pcpu-alloc: [0] 0
>>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>>> Total pages: 244080
>>> [    0.000000] Kernel command line: root=/dev/htifbd0 debug
>>> [    0.000000] PID hash table entries: 4096 (order: 2, 32768 bytes)
>>> [    0.000000] Dentry cache hash table entries: 262144 (order: 8, 2097152
>>> bytes)
>>> [    0.000000] Inode-cache hash table entries: 131072 (order: 7, 1048576
>>> bytes)
>>> [    0.000000] Memory: 1946872K/1966080K available (1762K kernel code,
>>> 136K rwdata, 368K rodata, 66K init, 248K bss, 19208K reserved)
>>> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>>> [    0.000000] NR_IRQS:8
>>> [    0.000000] console [htifcons0] enabled
>>> [    0.150000] Calibrating delay using timer specific routine.. 200.36
>>> BogoMIPS (lpj=1001806)
>>> [    0.150000] pid_max: default: 32768 minimum: 301
>>> [    0.150000] Mount-cache hash table entries: 4096 (order: 2, 32768
>>> bytes)
>>> [    0.150000] Mountpoint-cache hash table entries: 4096 (order: 2, 32768
>>> bytes)
>>> [    0.150000] devtmpfs: initialized
>>> [    0.150000] NET: Registered protocol family 16
>>> [    0.150000] htifcons: detected console with ID 1
>>> [    0.150000] bio: create slab <bio-0> at 0
>>> [    0.150000] Switched to clocksource riscv_clocksource
>>> [    0.160000] NET: Registered protocol family 2
>>> [    0.160000] TCP established hash table entries: 16384 (order: 4,
>>> 131072 bytes)
>>> [    0.160000] TCP bind hash table entries: 16384 (order: 4, 131072 bytes)
>>> [    0.160000] TCP: Hash tables configured (established 16384 bind 16384)
>>> [    0.160000] TCP: reno registered
>>> [    0.160000] UDP hash table entries: 1024 (order: 2, 32768 bytes)
>>> [    0.160000] UDP-Lite hash table entries: 1024 (order: 2, 32768 bytes)
>>> [    0.160000] NET: Registered protocol family 1
>>> [    0.160000] futex hash table entries: 256 (order: -1, 6144 bytes)
>>> [    0.160000] io scheduler noop registered
>>> [    0.160000] io scheduler cfq registered (default)
>>> [    0.220000] TCP: cubic registered
>>> [    0.230000] htifbd: detected disk with ID 2
>>> [    0.230000] htifbd: adding htifbd0
>>> [    0.230000] VFS: Mounted root (ext2 filesystem) readonly on device
>>> 254:0.
>>> [    0.230000] devtmpfs: mounted
>>> [    0.230000] Freeing unused kernel memory: 64K (ffffffff80002000 -
>>> ffffffff80012000)
>>> [    0.250000] EXT2-fs (htifbd0): warning: mounting unchecked fs, running
>>> e2fsck is recommended
>>> # [   73.600000] random: nonblocking pool is initialized
>>>
>>> #
>>> # ls
>>> bin         etc         lib         lost+found  sbin        tmp
>>> dev        linuxrc     proc        sys         usr
>>> # cd ^[[D^[[D^[[D^[[C^[[C^[[A^[[B
>>>
>>> After the boot, when I try to press arrow keys, it acts weird ( as seen
>>> above [[D^ etc ). One more difference I notice is, during the boot process
>>> for precompiled FPGA image provided, even these lines are executed and the
>>> command line doesnot act weird like in the above case. But, I am not able
>>> to execute the binaries I compile in either of them. Could you tell me what
>>> you think would be the problem?
>>>
>>> 2.   The SPECint benchmarks which you ran on FPGA, are they with the
>>> help of proxy kernel ? I was wondering if you recorded the runtime of the
>>> benchmarks? The link provided talks about miss rates and memory traffic.
>>>
>>> Thanks and regards,
>>> Pawan
>>>
>>>
>>>
>>
>> --
>> Pawan Reddy Sibbala
>> M.Eng ECE
>> Cornell University
>>
>>
>>
>




More information about the lowrisc-dev mailing list