riscvarchive / riscv-binutils-gdb Goto Github PK
View Code? Open in Web Editor NEWRISC-V backports for binutils-gdb. Development is done upstream at the FSF.
License: GNU General Public License v2.0
RISC-V backports for binutils-gdb. Development is done upstream at the FSF.
License: GNU General Public License v2.0
See also
RISC-V can provide up to 4162 regs
However in some cases some of these are not relevant to some targets - e.g. a target such as RV32IM with no FP capabilities has no FP regs; many of the CSRs are not actually implemented etc.
Should there be a mechanism whereby GDB can be told what the target architecture (and maybe also the applicable priv spec?) so that it can tune its register handling so that, for example, the GDB/MI -data-list-register-names command only returns the names of those registers relevant to the active target?
The set arch riscv:xxx command allows GDB to be told the target architecture but at the moment I think tha this is only used to specify rv32 or rv64 in order to adjust the size used for registers (and other data?).
Perhaps this could be extended to take an arbitrary RISC-V architecture token which could be used to tune how register handling is done?
If you need any more info please let me know.
Thanks
Tommy
I want to connect the gdb with a riscv32 CPU.
The gdb succeed to connect but it requires 64-bit width for all registers.
I want to know how I can set to 32bit version?
As far as I can see the RISC-V port of gdb defaults to using compressed breakpoint instructions for software breakpoints. This means that if the target does not support the C extension then you need to explicitly tell gdb otherwise an illegal instruction fault will happen when an attempt is made to executed the invalid (in a non C architecture context) instruction:
set riscv use_compressed_breakpoints no
This seems unnecessary complication in the implementation and hassle for the end user - why not simply use non compressed BP instructions which are supported by all targets whether C or not?
Is there some reason that compressed BP instructions are preferred by default?
Arch: RV*C
Test case 1 for disassembler:
$ cat t1.s
x:
li s5, -4096
$ riscv64-unknown-elf-gcc t1.s -c
$ riscv64-unknown-elf-objdump -d t1.o
0000000000000000 <x>:
0: 7afd lui s5,0xfffff
Expected result:
0000000000000000 <x>:
0: 7afd lui s5,-4096
Test case 2 for disassembler:
$ cat t4.s
x:
li s5, -4096
$ riscv64-unknown-elf-gcc t4.s -c -march=rv64ima
$ riscv64-unknown-elf-objdump -d t4.o
0000000000000000 <x>:
0: fffffab7 lui s5,0xfffff
Expected result:
0000000000000000 <x>:
0: fffffab7 lui s5,-4096
Test case 3 for assembler:
$ cat t2.s
x:
c.lui s5, -4096
$ riscv64-unknown-elf-gcc t2.s -c
t2.s: Assembler messages:
t2.s:2: Error: illegal operands `c.lui s5,-4096'
Expected result:
Accept the input.
Test case 4 for assembler:
$ cat t3.s
x:
lui s5, -4096
$ riscv64-unknown-elf-gcc t3.s -c -march=rv64ima
t3.s: Assembler messages:
t3.s:2: Error: lui expression not in range 0..1048575
Expected result:
Accept the input.
Hi,
I’ve implemented the mideleg/medeleg, hideleg/hedeleg and sideleg/sedeleg interrupt cascade mechanism.
The implementation I am working on has H-mode thus I've set mideleg/medeleg and hideleg/hedeleg to cascade interrupts to S-mode.
I’m getting an error with the toolchain (built from master) and it appears the hideleg/hedeleg (and likely sideleg/sedeleg) are not
src/rom/boot-pgtable.c: Assembler messages:
src/rom/boot-pgtable.c:131: Error: Instruction csrw requires absolute expression
src/rom/boot-pgtable.c:133: Error: Instruction csrw requires absolute expression
make[1]: *** [build/riscv64-unknown-elf/obj/boot-pgtable.o] Error 1
$ nl -b a src/rom/boot-pgtable.c | egrep '(131|133)'
131 write_csr(hideleg, interrupts);
133 write_csr(hedeleg, exceptions);
Michael
The code for determining whether a core implements C extension uses MISA, which is optional. How does/should GDB handle registers that don't exist?
"tries to read MISA", but it doesn't seem to check for any error status that might be returned by the target if MISA doesn't exist.
Should there be a canonical "not implemented" value returned if MISA is not implemented (as detected at a lower level)? Or should this code be checking the response from the target when it tries to read MISA?
GCC: riscvarchive/riscv-gcc@2540fd6
Binutils: 2dfac04
Arch: RV32* and RV64*
Option: -g -gdwarf-2
How to reproduce:
$ riscv64-unknown-linux-gnu-gcc pr65771.c -g -gdwarf-2 -c
/tmp/cctBkJjP.s: Assembler messages:
/tmp/cctBkJjP.s: Fatal error: internal error: bad relocation #72
Code for pr65771.c:
/* PR debug/65771 */
/* { dg-do link } */
/* { dg-require-effective-target tls_runtime } */
/* { dg-add-options tls } */
struct S { int s; int t; };
__thread struct S a[10];
int b;
int
main ()
{
int c = a[b].t;
(void) c;
return 0;
}
I am seeing a problem with the SLLI/SRLI/SRAI commands for a RV32I target. . I have been
communicating with Palmer Dabbelt - he suggested I post this as an issue/bug.
What follows are primitive test cases.
RV32I assembly source file
> cat test.s
.text
slli x31,x31,63
srli x31,x31,63
srai x31,x31,63
assemble in the installed RiscV tools /bin directory
./riscv32-unknown-elf-as test.s -o test.o
test.s: Assembler messages:
test.s:2: Warning: Improper shift amount (63)
test.s:3: Warning: Improper shift amount (63)
test.s:4: Warning: Improper shift amount (63)
create a list file
./riscv32-unknown-elf-objdump -h -l -M numeric,no-aliases -S -d -EL test.o
test.o: file format elf32-littleriscv
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000000c 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000040 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000040 2**0
ALLOC
Disassembly of section .text:
00000000 <.text>:
0: 03ff9f93 slli x31,x31,0x3f
4: 03ffdf93 srli x31,x31,0x3f
8: 43ffdf93 srai x31,x31,0x3f
The problem is the machine code for the 3 instructions are not following the spec for RV32I. It appears the 'shamt' field is overflowing into the higher order instruction words bits. According to the RiscV v2.1 spec, the upper 7 bits should be 0000000, 0000000, and 0100000 respectively for SLLI,SRLI, and SRAI.
I get the exact same list file and machine code for the following source code
.text
slli x31,x31,255
srli x31,x31,255
srai x31,x31,255
Both source files are 'overloading' the 'shamt' field width. My expectation is for truncation and the machine code to look like the following when programing a 63 shamt value
01ff9f93 slli x31,x31,0x3f
01ff9f93 srli x31,x31,0x3f
41ff9f93 srai x31,x31,0x3f
Lastly - the RiscV toolchain was built from source.
./riscv32-unknown-elf-as -v
GNU assembler version 2.28.51 (riscv32-unknown-elf) using BFD version (GNU Binutils) 2.28.51.20170101
This is on a recent 2017 install of openSUSE Leap 42.2
uname -a
Linux linux 4.4.49-16-default #1 SMP Sun Feb 19 17:40:35 UTC 2017 (70e9954) x86_64 x86_64 x86_64 GNU/Linux
cheers
Dave
What follows are a test case for SLTI command on RiscV assembler
cat testSLTI.s
.text
slti x0,x0,0xfff
assemble with 32 bit
./riscv32-unknown-elf-as testSLTI.s -o testSLTI.o
testSLTI.s: Assembler messages:
testSLTI.s:2: Error: illegal operands `slti x0,x0,0xfff'
assemble with 64 bit
./riscv64-unknown-elf-as testSLTI.s -o testSLTI.o
testSLTI.s: Assembler messages:
testSLTI.s:2: Error: illegal operands `slti x0,x0,0xfff'
I have no assembly errors with either 32 or 64 bit
with this source file below
.text
slti x0,x0,0x7ff
According to the RiscV v2.1 spec the immediate field width is 12 bits as indicated by "imm[11:0]" for SLTI. So why does this error on imm[11:0] = 0xfff ?
binutils revision levels
./riscv64-unknown-elf-as -v
GNU assembler version 2.28.51 (riscv64-unknown-elf) using BFD version (GNU Binutils) 2.28.51.20170101
./riscv32-unknown-elf-as testSLTI.s -v
GNU assembler version 2.28.51 (riscv32-unknown-elf) using BFD version (GNU Binutils) 2.28.51.20170101
I am having build errors regarding riscv-binutils-gdb
The errors are similar to the one below;
/home/promach/Documents/Grive/Personal/CPU/RISC-V/rocket-chip/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/gdb/guile/scm-ports.c:139:10: error: ‘scm_new_port_table_entry’ was not declared in this scope
port = scm_new_port_table_entry (port_type);
^~~~~~~~~~~~~~~~~~~~~~~~
I have attached the error log file in error.txt below.
My system configuration is as follows:
Arch Linux, gcc (GCC) 7.1.1 20170528 , GNU ld (GNU Binutils) 2.28.0.20170506
GCC: riscvarchive/riscv-gcc@2540fd6
Binutils: 2dfac04
Glibc: riscvarchive/riscv-glibc@7ba28f3
Arch: RV32IMA and RV32G
How to reproduce:
$ riscv32-unknown-linux-gnu-gcc anon5.C -gdwarf-2
/home/kito/riscv-workspace/rv32ima/lib/gcc/riscv32-unknown-linux-gnu/6.1.0/../../../../riscv32-unknown-linux-gnu/bin/ld: Dwarf Error: mangled line number section.
/tmp/ccvn2QJe.o: In function `.LCFI1':
anon5.C:(.text+0xc): undefined reference to `(anonymous namespace)::c::t'
anon5.C:(.text+0x10): undefined reference to `(anonymous namespace)::c::t'
collect2: error: ld returned 1 exit status
Note: undefined reference is expected output.
Code for anon5.C:
// PR c++/34094
// { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
// { dg-options "-gdwarf-2" }
// Ignore additional message on powerpc-ibm-aix
// { dg-prune-output "obtain more information" } */
// Ignore additional messages on Linux/x86 with PIE
// { dg-prune-output "Bad value" } */
namespace {
struct c
{
static const bool t = 0;
};
}
const bool &f()
{
return c::t; // { dg-message "\[Uu\]ndefined" "undefined" { target *-*-* } 0 }
// Some targets report the error for the previous line, others
// don't give line number inforamtion for it, so use line 0.
}
int main(void)
{
return 0;
}
It's probably just me but I'm hopelessly confused by the build and install process here. What environment variables if any do I need to set to make sure the right binary gets built, and where it gets installed? What branch should I use?
Hi, when building I received the warning of implicit declaration of function of wcwidth() in
riscv-binutils-gdb/readline/mbutil.c
I googled it and found out that it is included wchar.h, but I didn't see #include<wchar.h> in mbutil.c. Do you think you missed it or are there any other explanations for this warning?
Hi:
I have built the RISC-V GDB tool from this git
here is my steps to build it:
git clone https://github.com/riscv/riscv-binutils-gdb.git
cd riscv-binutils-gdb
mkdir build
cd build
../configure --target=riscv32-unknown-elf --prefix=/opt/riscv32gdb
make
make install
after doing this, I used gdb to connect with advance debug, the result as follows :
(gdb) target remote :1234
Remote debugging using :1234
(gdb) load
Loading section .vectors, size 0x8c lma 0x0
Loading section .text, size 0x220 lma 0x8c
Loading section .text.startup.main, size 0x4c lma 0x2ac
Loading section .text.illegal_insn_handler_c, size 0x2c lma 0x2f8
Loading section .text.qprinti.constprop.2, size 0x3e4 lma 0x324
Loading section .text.printf, size 0x7a0 lma 0x708
Loading section .text.puts, size 0x60 lma 0xea8
Loading section .text.set_pin_function, size 0x48 lma 0xf08
Loading section .text.set_gpio_pin_direction, size 0x68 lma 0xf50
Loading section .text.set_gpio_pin_value, size 0x68 lma 0xfb8
Loading section .text.int_time_cmp, size 0x4 lma 0x1020
Loading section .text.int_main, size 0x58 lma 0x1024
Loading section .text.uart_set_cfg, size 0x50 lma 0x107c
Loading section .text.uart_sendchar, size 0x1c lma 0x10cc
Loading section .text.uart_wait_tx_done, size 0x14 lma 0x10e8
Loading section .text.eoc, size 0x60 lma 0x10fc
Loading section .text.exit, size 0x10 lma 0x115c
Loading section .rodata, size 0x1b8 lma 0x100000
Loading section .eh_frame, size 0x190 lma 0x1001b8
Loading section .data, size 0x10 lma 0x100348
Loading section .sdata.setme, size 0x4 lma 0x100358
Loading section .sdata.setme2, size 0x4 lma 0x10035c
Start address 0x8c, load size 5324
Transfer rate: 1 KB/sec, 242 bytes/write.
(gdb) info registers
The current thread has terminated
(gdb)
I can load code to memory,but i can't use other gdb command,such as info,set $pc ....
I'm trying to build the RISC-V toolchain on a Raspberry Pi 3 (which later on is supposed to assemble randomly generated RISC-V assembly for automated over-night tests of a RV32-core). The Raspberry Pi runs Raspian, which is basically Debian for ARMv6.
Building the simulator fails at sim-main.c, line 607:
#ifdef __GNUC__
return ((__int128)a * b) >> 64;
#else
// alternative implementation here
#endif
Turns out that checking for GNUC is not sufficient to guarantee that __int128 is available:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
There is no support in GCC for expressing an integer constant of type __int128 for targets with long long integer less than 128 bits wide.
According to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch08s02.html long long on ARM is 64 bits, not 128 bits, suggesting that __int128 is not available there.
The solution may be to ensure that the alternative code path is chosen. A clunky solution may be something like
#if defined(__GNU__) && !defined(__ARM__)
although a less platform-specific check may be possible and preferable.
Hello, I think there is a small error in the disassembly.
The following instruction 1000f9f3
(in big endian) is disassembled to csrrc s3,sstatus,1
but should actually be csrrci s3,sstatus,1
as seems obvious by the immediate operand 1
. This is further backed upd by the spec 2.1 where csrrci
is given for the funct3
of 0b111
.
I'm using the bottled package (e.g. prebuilt) from https://github.com/riscv/homebrew-riscv
Thanks.
The instructions fmv.x.w and fmv.w.x are the new names of fmv.x.s and fmv.s.x, respectively. We do not currently accept the new names. We should fix both the assembler and disassembler (but continue to accept the old names in the assembler).
Arch: RV32 and RV64
After this commit 6ec11ab, I can't run static link program with qemu, and it's work if revert that.
GCC: riscvarchive/riscv-gcc@cd5c51b
GLIBC: riscvarchive/riscv-glibc@e84d3a5
QEMU: riscvarchive/riscv-qemu@21e3a7c
riscv-gnu-toolchain: riscv-collab/riscv-gnu-toolchain@914224e
How to reproduce:
$ cat hello.c
#include <stdio.h>
int main(int argc, const char *argv[]){
printf("Hello world\n");
return 0;
}
$ riscv64-unknown-linux-gnu-gcc hello.c -o hello.rv64 -static
$ qemu-riscv64 hello.rv64
Segmentation fault (core dumped)
See also:
As the subject says - could/should GDB/MI -data-list-register-names return ABI rather than canonical names for some or all of integer regs. FP regs and CSRs - either automatically or as a configurable option?
Are there situations in which some users want to see "raw" canonical names?
Are there situations in which other ABIs/register naming conventions might be used?
Shouldn't GDB/MI -data-list-register-names and the likes of info registers/info all-registers generate consistent output (they don't right now)?
If ABI names are used then might it also be necessary to cater for targets adhering to different versions of the (draft) priv spec - e.g. 1.9, 1.9.1, 1.10 and provide a command to tell GDB which priv spec should apply?
Are there other issues to consider?
If you need any more info please let me know.
Thanks
Tommy
I believe this is the latest code review. I'm putting it here so it doesn't get lost
Hi
This is probably more a question than an issue. I'm not even sure if this is possible, but at the moment I'm trying to compile the binutils so I will get gdb-server which could be run natively on the riscv linux. My goal is to be able to debug remotely user space application inside the riscv linux.
I use the riscv-next branch and configure it with these commands:
./configure --prefix=$RISCV --host=riscv64-unknown-linux-gnu --target=riscv64-unknown-linux-gnu
And it the end it outputs these errors:
proc-service.o: In function `ps_xfer_memory':
/home/antonkrug/riscv-binutils-gdb-riscv-next/gdb/proc-service.c:89: undefined reference to `fill_gregset(regcache const*, unsigned long long (*) [32], int)'
/home/antonkrug/riscv-binutils-gdb-riscv-next/gdb/proc-service.c:89: undefined reference to `supply_gregset(regcache*, unsigned long long const (*) [32])'
/home/antonkrug/riscv-binutils-gdb-riscv-next/gdb/proc-service.c:89: undefined reference to `fill_fpregset(regcache const*, double (*) [32], int)'
/home/antonkrug/riscv-binutils-gdb-riscv-next/gdb/proc-service.c:89: undefined reference to `supply_fpregset(regcache*, double const (*) [32])'
collect2: error: ld returned 1 exit status
Makefile:2242: recipe for target 'gdb' failed
make[2]: *** [gdb] Error 1
make[2]: Leaving directory '/home/antonkrug/riscv-binutils-gdb-riscv-next/gdb'
Makefile:10420: recipe for target 'all-gdb' failed
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory '/home/antonkrug/riscv-binutils-gdb-riscv-next'
Makefile:849: recipe for target 'all' failed
make: *** [all] Error 2
I attached the whole log file
gdbserver-build.txt
Compiling the kernel, busybox and making my own rootfs works well, I only get stuck at step. Could somebody point me to the right direction or if this is even feasible or not?
If you start a 64-bit gdb, and immediately connect it to a 32-bit target, gdb will think the target is 64 bits. Register values won't be interpreted correctly, and generally the setup is unusable. If you give gdb an ELF file, it will find XLEN from there. You can also explicitly force gdb to 32-bit using set arch riscv:rv32
.
To solve this nicely, the server gdb connects to (eg. OpenOCD) would have to return a different target description for RV32 versus RV64 cores. https://sourceware.org/ml/gdb/2016-10/msg00015.html describes roughly what work is required to accomplish this.
The fsrmi and fsflagsi pseudo-ops defined in the 2.2 RISC-V ISA manual are not recognized with the latest toolchain. The register forms of the pseudo-ops compile.
Attempting to compile the following code:
#include <stdio.h>
int main(int argc, char **argv)
{
int rd, rs;
asm volatile("frrm %0" : "=r"(rd));
asm volatile("fsrm %0, %1" : "=r"(rd) : "r"(rs));
asm volatile("fsrm %0" : : "r"(rs));
asm volatile("fsrmi %0, %1" : "=r"(rd) : "i"(0));
asm volatile("fsrmi %0" : : "i"(0));
asm volatile("frflags %0" : "=r"(rd));
asm volatile("fsflags %0, %1" : "=r"(rd) : "r"(rs));
asm volatile("fsflags %0" : : "r"(rs));
asm volatile("fsflagsi %0, %1" : "=r"(rd) : "i"(0));
asm volatile("fsflagsi %0" : : "i"(0));
}
Results in the following errors:
$ riscv64-unknown-elf-gcc -o /tmp/test /tmp/test-pseudo-ops.c
/tmp/test-pseudo-ops.c: Assembler messages:
/tmp/test-pseudo-ops.c:11: Error: unrecognized opcode `fsrmi a5,0'
/tmp/test-pseudo-ops.c:12: Error: unrecognized opcode `fsrmi 0'
/tmp/test-pseudo-ops.c:17: Error: unrecognized opcode `fsflagsi a5,0'
/tmp/test-pseudo-ops.c:18: Error: unrecognized opcode `fsflagsi 0'
$
$ CFLAGS=-Og ./configure --prefix=$RISCV --target=riscv64-unknown-elf --enable-tui --disable-werror
...
$ make
...
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DHAVE_riscv_elf64_vec -DHAVE_riscv_elf32_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -DBINDIR=\"/opt/riscv/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I./../zlib -Og -MT elf64-riscv.lo -MD -MP -MF .deps/elf64-riscv.Tpo -c elf64-riscv.c -o elf64-riscv.o
./elfnn-riscv.c: In function ‘riscv_free_pcgp_relocs’:
./elfnn-riscv.c:2752:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
What am I missing?
(I am assuming that riscv-next is the current development branch, where new development should be done.)
gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"RV64G"' -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=64 -DWITH_TARGET_BYTE_ORDER=BFD_ENDIAN_LITTLE -DDEFAULT_INLINE=0 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -I. -I/Users/bernd/Projects/github.com/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv -I../common -I/Users/bernd/Projects/github.com/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../common -I../../include -I/Users/bernd/Projects/github.com/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../../include -I../../bfd -I/Users/bernd/Projects/github.com/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../../bfd -I../../opcodes -I/Users/bernd/Projects/github.com/riscv-tools/riscv-gnu-toolchain/build/../riscv-binutils-gdb/sim/riscv/../../opcodes -I../../intl -g -O2 -Wl,-no_pie -o run \
nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../intl/libintl.a -liconv ../../libiberty/libiberty.a -L../../zlib -lz -lrt -ldl
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [run] Error 1
make[3]: *** [all] Error 1
make[2]: *** [all-sim] Error 2
make[1]: *** [all] Error 2
make: *** [stamps/build-binutils-newlib] Error 2
macOS Sierra 10.12.1
Xcode 8.1
riscv-gnu-toolchain commit 87ec00322ed6caa207747ce00ed38ca15995ec63
EDIT: I can reproduce a failure with objdump alone which seems very similar.
[root@sorear6 tmp]# cat 19.c
long test(int *x, long *y) {
asm("fence.i"); /* so we can find it later */
return (*x + *x) + *y;
}
[root@sorear6 tmp]# cc -shared -O 19.c
[root@sorear6 tmp]# objdump -d a.out | grep -A5 fence.i
4fc: 0000100f fence.i
500: 00052783 lw a5,0(a0)
504: 0017979b slliw a5,a5,0x1
508: 0005b503 ld a0,0(a1)
50c: 00a78533 add a0,a5,a0
510: 00008067 ret
[root@sorear6 tmp]# objdump -b binary -m riscv:rv64 -D a.out | grep -A5 fence.i
4fc: 0f100000 fence.i
500: 83270500 lw a5,0(a0)
504: 9b971700 0x17979b
508: 03b50500 0x5b503
50c: 3385a700 add a0,a5,a0
510: 67800000 ret
Doing experiments on the version of gdb in the Fedora RISC-V porting project. It's conceivable these are packaging bugs; let me know if you need any additional information.
Exhibit A, the main function in /bin/ls as disassembled by objdump:
bash-4.3# objdump --version
GNU objdump (GNU Binutils) 2.26.0.20160516
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
bash-4.3# objdump -d /bin/ls | grep -A80 'main>:'
000000000001b0c0 <main>:
1b0c0: cc010113 addi sp,sp,-832
1b0c4: 32813823 sd s0,816(sp)
1b0c8: 00050413 mv s0,a0
1b0cc: 0005b503 ld a0,0(a1)
1b0d0: 32113c23 sd ra,824(sp)
1b0d4: 32913423 sd s1,808(sp)
1b0d8: 33213023 sd s2,800(sp)
1b0dc: 31313c23 sd s3,792(sp)
1b0e0: 2fa13023 sd s10,736(sp)
1b0e4: 00058913 mv s2,a1
1b0e8: 31413823 sd s4,784(sp)
1b0ec: 31513423 sd s5,776(sp)
1b0f0: 31613023 sd s6,768(sp)
1b0f4: 2f713c23 sd s7,760(sp)
1b0f8: 2f813823 sd s8,752(sp)
1b0fc: 2f913423 sd s9,744(sp)
1b100: 2db13c23 sd s11,728(sp)
1b104: 00017d37 lui s10,0x17
1b108: 1710a0ef jal 25a78 <set_program_name>
1b10c: 968d0593 addi a1,s10,-1688 # 16968 <__mon_yday+0x3210>
1b110: 00600513 li a0,6
1b114: f1dff0ef jal 1b030 <setlocale@plt>
1b118: 000154b7 lui s1,0x15
1b11c: 000155b7 lui a1,0x15
1b120: 6d058593 addi a1,a1,1744 # 156d0 <__mon_yday+0x1f78>
1b124: 6e848513 addi a0,s1,1768 # 156e8 <__mon_yday+0x1f90>
1b128: f49ff0ef jal 1b070 <bindtextdomain@plt>
1b12c: 6e848513 addi a0,s1,1768
1b130: bc1ff0ef jal 1acf0 <textdomain@plt>
1b134: 00023537 lui a0,0x23
1b138: 00200993 li s3,2
1b13c: 9cc50513 addi a0,a0,-1588 # 229cc <close_stdout>
1b140: 8b31a823 sw s3,-1872(gp) # 16af8 <exit_failure>
1b144: 79d130ef jal 2f0e0 <atexit>
1b148: 89c1a483 lw s1,-1892(gp) # 16ae4 <ls_mode>
1b14c: 00018737 lui a4,0x18
1b150: d0070713 addi a4,a4,-768 # 17d00 <rpl_optarg+0x400>
1b154: fff00793 li a5,-1
1b158: 00070613 mv a2,a4
1b15c: 9201a423 sw zero,-1752(gp) # 16b70 <exit_status>
1b160: 00100693 li a3,1
1b164: 02e13023 sd a4,32(sp)
1b168: 94d18423 sb a3,-1720(gp) # 16b90 <print_dir_name>
1b16c: 03f79713 slli a4,a5,0x3f
1b170: 98f63023 sd a5,-1664(a2)
1b174: 9e01bc23 sd zero,-1544(gp) # 16c40 <pending_dirs>
1b178: 96e63c23 sd a4,-1672(a2)
1b17c: 96018423 sb zero,-1688(gp) # 16bb0 <qmark_funny_chars>
1b180: 77348063 beq s1,s3,1b8e0 <main+0x820>
1b184: 00300a13 li s4,3
1b188: 75448263 beq s1,s4,1b8cc <main+0x80c>
1b18c: 00100793 li a5,1
1b190: 00f48463 beq s1,a5,1b198 <main+0xd8>
1b194: e8dff0ef jal 1b020 <abort@plt>
1b198: 00048513 mv a0,s1
1b19c: cb5ff0ef jal 1ae50 <isatty@plt>
1b1a0: 00050463 beqz a0,1b1a8 <main+0xe8>
1b1a4: 6d40106f j 1c878 <main+0x17b8>
1b1a8: 9c91a423 sw s1,-1592(gp) # 16c10 <format>
1b1ac: 9c01a223 sw zero,-1596(gp) # 16c0c <time_type>
1b1b0: 9c01a023 sw zero,-1600(gp) # 16c08 <sort_type>
1b1b4: 9a018fa3 sb zero,-1601(gp) # 16c07 <sort_reverse>
1b1b8: 9a018ea3 sb zero,-1603(gp) # 16c05 <numeric_ids>
1b1bc: 9a018e23 sb zero,-1604(gp) # 16c04 <print_block_size>
1b1c0: 98018623 sb zero,-1652(gp) # 16bd4 <print_inode>
1b1c4: 00100793 li a5,1
1b1c8: 98f1a423 sw a5,-1656(gp) # 16bd0 <dereference>
1b1cc: 98018323 sb zero,-1658(gp) # 16bce <recursive>
1b1d0: 980182a3 sb zero,-1659(gp) # 16bcd <immediate_dirs>
1b1d4: 9601bc23 sd zero,-1672(gp) # 16bc0 <ignore_patterns>
1b1d8: 00015537 lui a0,0x15
1b1dc: 9601b823 sd zero,-1680(gp) # 16bb8 <hide_patterns>
1b1e0: 6f850513 addi a0,a0,1784 # 156f8 <__mon_yday+0x1fa0>
1b1e4: 9a01a223 sw zero,-1628(gp) # 16bec <indicator_style>
1b1e8: 9801a023 sw zero,-1664(gp) # 16bc8 <ignore_mode>
1b1ec: 9e018aa3 sb zero,-1547(gp) # 16c3d <print_scontext>
1b1f0: b81ff0ef jal 1ad70 <getenv@plt>
1b1f4: 00050493 mv s1,a0
1b1f8: 04050063 beqz a0,1b238 <main+0x178>
1b1fc: 000139b7 lui s3,0x13
Exhibit B, as disassembled by gdb:
bash-4.3# gdb /bin/ls
GNU gdb (GDB) 7.10.50.20160516-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "riscv64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/ls...done.
(gdb) x /80i main
0x1b0c0 <main>: addi sp,sp,-832
0x1b0c4 <main+4>: 0x32813823
0x1b0c8 <main+8>: mv s0,a0
0x1b0cc <main+12>: 0x5b503
0x1b0d0 <main+16>: 0x32113c23
0x1b0d4 <main+20>: 0x32913423
0x1b0d8 <main+24>: 0x33213023
0x1b0dc <main+28>: 0x31313c23
0x1b0e0 <main+32>: 0x2fa13023
0x1b0e4 <main+36>: mv s2,a1
0x1b0e8 <main+40>: 0x31413823
0x1b0ec <main+44>: 0x31513423
0x1b0f0 <main+48>: 0x31613023
0x1b0f4 <main+52>: 0x2f713c23
0x1b0f8 <main+56>: 0x2f813823
0x1b0fc <main+60>: 0x2f913423
0x1b100 <main+64>: 0x2db13c23
0x1b104 <main+68>: lui s10,0x17
0x1b108 <main+72>: jal 0x25a78 <set_program_name>
0x1b10c <main+76>: addi a1,s10,-1688
0x1b110 <main+80>: li a0,6
0x1b114 <main+84>: jal 0x1b030 <setlocale@plt>
0x1b118 <main+88>: lui s1,0x15
0x1b11c <main+92>: lui a1,0x15
0x1b120 <main+96>: addi a1,a1,1744
0x1b124 <main+100>: addi a0,s1,1768
0x1b128 <main+104>: jal 0x1b070 <bindtextdomain@plt>
0x1b12c <main+108>: addi a0,s1,1768
0x1b130 <main+112>: jal 0x1acf0 <textdomain@plt>
0x1b134 <main+116>: lui a0,0x23
0x1b138 <main+120>: li s3,2
0x1b13c <main+124>: addi a0,a0,-1588
0x1b140 <main+128>: sw s3,-1872(gp)
0x1b144 <main+132>: jal 0x2f0e0 <atexit>
0x1b148 <main+136>: lw s1,-1892(gp)
0x1b14c <main+140>: lui a4,0x18
0x1b150 <main+144>: addi a4,a4,-768
0x1b154 <main+148>: li a5,-1
0x1b158 <main+152>: mv a2,a4
0x1b15c <main+156>: sw zero,-1752(gp)
0x1b160 <main+160>: li a3,1
0x1b164 <main+164>: 0x2e13023
0x1b168 <main+168>: sb a3,-1720(gp)
0x1b16c <main+172>: slli a4,a5,0x3f
0x1b170 <main+176>: 0x98f63023
0x1b174 <main+180>: 0x9e01bc23
0x1b178 <main+184>: 0x96e63c23
0x1b17c <main+188>: sb zero,-1688(gp)
0x1b180 <main+192>: beq s1,s3,0x1b8e0 <main+2080>
0x1b184 <main+196>: li s4,3
0x1b188 <main+200>: beq s1,s4,0x1b8cc <main+2060>
0x1b18c <main+204>: li a5,1
0x1b190 <main+208>: beq s1,a5,0x1b198 <main+216>
0x1b194 <main+212>: jal 0x1b020 <abort@plt>
0x1b198 <main+216>: mv a0,s1
0x1b19c <main+220>: jal 0x1ae50 <isatty@plt>
0x1b1a0 <main+224>: beqz a0,0x1b1a8 <main+232>
0x1b1a4 <main+228>: j 0x1c878 <main+6072>
0x1b1a8 <main+232>: sw s1,-1592(gp)
0x1b1ac <main+236>: sw zero,-1596(gp)
0x1b1b0 <main+240>: sw zero,-1600(gp)
0x1b1b4 <main+244>: sb zero,-1601(gp)
0x1b1b8 <main+248>: sb zero,-1603(gp)
0x1b1bc <main+252>: sb zero,-1604(gp)
0x1b1c0 <main+256>: sb zero,-1652(gp)
0x1b1c4 <main+260>: li a5,1
0x1b1c8 <main+264>: sw a5,-1656(gp)
0x1b1cc <main+268>: sb zero,-1658(gp)
0x1b1d0 <main+272>: sb zero,-1659(gp)
0x1b1d4 <main+276>: 0x9601bc23
0x1b1d8 <main+280>: lui a0,0x15
0x1b1dc <main+284>: 0x9601b823
0x1b1e0 <main+288>: addi a0,a0,1784
0x1b1e4 <main+292>: sw zero,-1628(gp)
0x1b1e8 <main+296>: sw zero,-1664(gp)
0x1b1ec <main+300>: sb zero,-1547(gp)
0x1b1f0 <main+304>: jal 0x1ad70 <getenv@plt>
0x1b1f4 <main+308>: mv s1,a0
0x1b1f8 <main+312>: beqz a0,0x1b238 <main+376>
0x1b1fc <main+316>: lui s3,0x13
Test case
https://uclibc.org/~kraj/riscv-linker-test.tar.bz2
Fails to link
$ /opt/riscv/bin/riscv64-unknown-linux-gnu-gcc nss.c -lnss3 -L. -Wl,-rpath-link .
/opt/riscv/lib/gcc/riscv64-unknown-linux-gnu/7.1.1/../../../../riscv64-unknown-linux-gnu/bin/ld: /opt/riscv/sysroot/usr/lib64/lp64d/crt1.o: undefined reference to symbol '__global_pointer$'
./libplc4.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
This example works ok on other architectures. Adding -lplc4
to cmdline then link succeeds. Issue is observed in multiple packages.
Here is DT_NEEDED entries for libnss3.so
Dynamic section at offset 0xaddc0 contains 32 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libnssutil3.so]
0x0000000000000001 (NEEDED) Shared library: [libplc4.so]
0x0000000000000001 (NEEDED) Shared library: [libplds4.so]
0x0000000000000001 (NEEDED) Shared library: [libnspr4.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-riscv64-lp64d.so.1]
0x000000000000000e (SONAME) Library soname: [libnss3.so]
The riscv simulator depends on Linux's clock_gettime, which prevents this from being compiled on any other platform such as OS X, even if gcc is used. Since this repo is a dependency of riscv-gnu-toolchain, this restriction makes any other OS incapable of using riscv-gcc.
clock_gettime is used to implement CSR_TIME (in sim/riscv/sim-main.c), but it seems any timing mechanism could also be used. Some possibilities include:
Are there are other constraints? Could one of the above suggestions work?
Hi,
For example, when GDB want to probe the value of a function variable at (for example) s0-28, it does the access by using sp-28, which return the wrong value.
From what I gather online, this seems to have been an issue since upstream guile deprecated structures used by gdb.
https://sourceware.org/bugzilla/show_bug.cgi?id=21104
crosstool-ng/crosstool-ng#799
http://archive.linuxfromscratch.org/mail-archives/blfs-dev/2017-March/033056.html
crosstool-ng/crosstool-ng#718
Upstream GDB side-stepped the issue last week by defaulting to guile 2.0 unless otherwise specified. The suggested fix is to include --without-guile
or --with-guile=no
in GDB's configure scripts. My system has guile 2.2.2 installed, which explains the inability to find the missing types. It is likely that installing an earlier version of Guile would also remedy the situation.
This issue was posted here before I realized the specifics of the problem.
Trying to build this package I get the following error:
gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"RV64G"' -DPROFILE=1 -DWITH_PROFILE=-1 -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_TARGET_WORD_BITSIZE=64 -DWITH_TARGET_BYTE_ORDER=LITTLE_ENDIAN -DWITH_ENVIRONMENT=ALL_ENVIRONMENT -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -I. -I../../../sim/riscv -I../common -I../../../sim/riscv/../common -I../../include -I../../../sim/riscv/../../include -I../../bfd -I../../../sim/riscv/../../bfd -I../../opcodes -I../../../sim/riscv/../../opcodes -g -O2 -c -o sim-model.o -MT sim-model.o -MMD -MP -MF .deps/sim-model.Tpo ../../../sim/riscv/../common/sim-model.c
../../../sim/riscv/../common/sim-model.c: In function ‘model_set’:
../../../sim/riscv/../common/sim-model.c:108:3: warning: implicit declaration of function ‘CPU_MACH’ [-Wimplicit-function-declaration]
CPU_MACH (cpu) = MODEL_MACH (model);
^
../../../sim/riscv/../common/sim-model.c:108:18: error: lvalue required as left operand of assignment
CPU_MACH (cpu) = MODEL_MACH (model);
^
../../../sim/riscv/../common/sim-model.c:109:3: warning: implicit declaration of function ‘CPU_MODEL’ [-Wimplicit-function-declaration]
CPU_MODEL (cpu) = model;
^
../../../sim/riscv/../common/sim-model.c:109:19: error: lvalue required as left operand of assignment
CPU_MODEL (cpu) = model;
^
[....]
I'm trying to build using the following sequence of commands (same with --target=riscv32
):
mkdir build
cd build/
../configure --program-prefix=riscv- --target=riscv
make
Also: How does this package relate to https://github.com/mythdraenor/riscv-gdb? The webpage (http://riscv.org/download.html#tab_gdb) points to that repo, but it has not seen an update in over a year..
Hi,
I am trying to work with buildroot to create the risv64 toolchain and later create my vmlinux.
My buildroot tree is based on SiFive work and can be seen at this branch
Here is my patch
Note: I use for binutils. gcc, glibc, and linux headers the riscv-next branch.
To reproduce
I do:
make mlx_riscv64_defconfig
make
I get an error during glibc build phase similar to #84 see below log:
I tried the FIX proposed to riscv32 slightly changed, but it did not help.
The modified patch can be seen embedded in above link.
Any ideas?
/home/noam/workspace/newenv/buildroot/output/host/usr/bin/riscv64-buildroot-linux-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux-riscv64-lp64d.so.1 -B/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/csu/ -Wl,--version-script=/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/math -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/dlfcn -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nss -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nis -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/rt -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/resolv -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/crypt -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/mathvec -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/support -L/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nptl -Wl,-rpath-link=/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/math:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/dlfcn:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nss:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nis:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/rt:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/resolv:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/crypt:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/mathvec:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/support:/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/nptl -o /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/linkobj/libc.so -T /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/shlib.lds /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/csu/abi-note.o /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf/soinit.os -Wl,--whole-archive /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/linkobj/libc_pic.a -Wl,--no-whole-archive /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf/sofini.os /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf/interp.os /home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/elf/ld.so -lgcc
/home/noam/workspace/newenv/buildroot/output/host/usr/lib/gcc/riscv64-buildroot-linux-gnu/8.0.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: .eh_frame_hdr refers to overlapping FDEs.
/home/noam/workspace/newenv/buildroot/output/host/usr/lib/gcc/riscv64-buildroot-linux-gnu/8.0.0/../../../../riscv64-buildroot-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makerules:763: recipe for target '/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/linkobj/libc.so' failed
make[3]: *** [/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/build/linkobj/libc.so] Error 1
Makefile:9: recipe for target 'all' failed
make[2]: *** [all] Error 2
package/pkg-generic.mk:227: recipe for target '/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/.stamp_built' failed
make[1]: *** [/home/noam/workspace/newenv/buildroot/output/build/glibc-riscv-next/.stamp_built] Error 2
Makefile:79: recipe for target '_all' failed
make: *** [_all] Error 2
riscv-gnu-toolchain/riscv-binutils-gdb/gdb/common/gdb_unlinker.h:35:35: error: '__nonnull__' attribute is invalid for the implicit this argument
unlinker (const char *filename) ATTRIBUTE_NONNULL (1)
gdb built from 2e8a797 aborts with the following error:
/usr/local/src/riscv-gnu-toolchain/riscv-binutils-gdb/gdb/gdbarch.c:701: internal-error: verify_gdbarch: the following are invalid ...
breakpoint_kind_from_pc
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
It appears that riscv-tdep.c
is missing the gdbarch method breakpoint_kind_from_pc
, which was added by upstream commit cd6c3b4.
Proposed patch in #20
A more robust fix for additional OSes might be required.
See riscv-collab/riscv-gnu-toolchain#190
r_format opcode, funct3, func7, rd, rs1, rs2
i_format opcode, funct3, rd, rs1, immed
s_format opcode, funct3, rs1, rs2, immed
sb_format opcode, funct3, rs1, rs2, immed (or label?)
u_format opcode, rd, immed
uj_format opcode, rd, immed (or label?)
r4_format opcode, funct3, funct2, rd, rs1, rs2, rs3
cr_format op, funct4, rd/rs1, rs2
... C-space is pretty full so it may not make sense
.word
doesn't support register names, so it's harder to use with gcc inline asm.
When attempting to build riscv-binutils from riscv-gnu-toolchain, I get the following error when building ld.info:
if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \
for f in ld.info ld.info-[0-9] ld.info-[0-9][0-9] ld.i[0-9] ld.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi && \
if makeinfo --split-size=5000000 --split-size=5000000 -I /home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld -I /home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/../bfd/doc -I ../bfd/doc -I /home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/../libiberty -I /home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld \
-o ld.info `test -f 'ld.texinfo' || echo '/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/'`ld.texinfo; \
then \
rc=0; \
else \
rc=$?; \
$restore $backupdir/* `echo "./ld.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:358: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:2428: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:2908: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:2940: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:2968: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:2990: table requires an argument: the formatter for @item
'home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:4618: unknown command `
'home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/ld/ld.texinfo:4622: unknown command `
Makefile:1572: recipe for target 'ld.info' failed
make[4]: *** [ld.info] Error 1
make[4]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/ld'
Makefile:1757: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/ld'
Makefile:989: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/ld'
Makefile:7181: recipe for target 'all-ld' failed
make[1]: *** [all-ld] Error 2
make[1]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib'
Makefile:857: recipe for target 'all' failed
make: *** [all] Error 2
For reference, I built binutils 2.27 from source recently on Windows (1-8-2017) to report a bug, and there were no issues compiling. In fact, according to my still-present build-tree, EDIT: The info files were in fact built in my compile, checking the installed files.ld.info
wasn't built at all, although there is nothing to suggest in the MinGW patches that building info files is disabled.
touch ld/ld.info
in the build tree to skip building works fine on Windows. , but I wonder what causes the target to be build at all compared to a "vanilla" MinGW binutils build.
EDIT: Also touch gas/doc/as.info
for the make install
step, otherwise the following errors occur:
if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \
for f in as.info as.info-[0-9] as.info-[0-9][0-9] as.i[0-9] as.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi && \
if makeinfo --split-size=5000000 --split-size=5000000 -I "/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc" -I "/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/../libiberty" -I "/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/../bfd/doc" -I ../../bfd/doc -I /home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc \
-o as.info `test -f 'as.texinfo' || echo '/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/'`as.texinfo; \
then \
rc=0; \
else \
rc=$?; \
$restore $backupdir/* `echo "./as.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:619: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:625: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:914: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:928: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:981: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:992: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1073: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1091: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1107: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1128: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1149: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1197: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1227: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1264: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1316: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1340: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1356: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1590: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1709: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:1814: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:2392: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/as.texinfo:7113: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-aarch64.texi:35: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-alpha.texi:42: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-bfin.texi:30: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-epiphany.texi:31: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-h8300.texi:28: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-i386.texi:56: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-nios2.texi:32: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-ppc.texi:38: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-pru.texi:26: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-riscv.texi:27: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-tic6x.texi:29: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-tilegx.texi:29: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-visium.texi:32: table requires an argument: the formatter for @item
/home/William/src/riscv-gnu-toolchain/riscv-binutils-gdb/gas/doc/c-xtensa.texi:34: table requires an argument: the formatter for @item
Makefile:433: recipe for target 'as.info' failed
make[4]: *** [as.info] Error 1
make[4]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/gas/doc'
Makefile:631: recipe for target 'install-am' failed
make[3]: *** [install-am] Error 2
make[3]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/gas/doc'
Makefile:2271: recipe for target 'install-recursive' failed
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib/gas'
Makefile:4973: recipe for target 'install-gas' failed
make[1]: *** [install-gas] Error 2
make[1]: Leaving directory '/home/William/src/riscv-gnu-toolchain/build-binutils-newlib'
Makefile:2263: recipe for target 'install' failed
make: *** [install] Error 2
All other info files build without error.
c.srli s0,xx is generated instead. Other registers and compressed instructions appear to be fine.
This came as part of the binutils submission feedback
Hi Palmer,
Just noticed this:
> diff --git a/gas/config/tc-riscv.c b/gas/config/tc-riscv.c
[...]
> +/* Pseudo-op table. */
> +static const pseudo_typeS riscv_pseudo_table[] =
> + {"p2align", s_align, 0},
This breaks one of the gas testsuite's tests (gas/testsuite/gas/all/align.s)
because it does not support the third argument to the normal
.p2align pseudo-op. It also means that .p2align pseudo-op does
not behave as documented when the target is the riscv.
Please could you consider extending your s_align() function to
handle the extra argument.
Cheers
Nick
@kuanlinchentw I think this comment is wrong: https://github.com/riscv/riscv-binutils-gdb/blob/riscv-next/bfd/elfxx-riscv.c#L837
See https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/jCDmiB6Vfrk
Run riscv64-unknown-elf-gdb in GDB/MI mode and execute the -data-list-register-names command:
$ riscv64-unknown-elf-gdb -i mi riscv-systick-blinky.elf
=thread-group-added,id="i1"
~"GNU gdb (GDB) 7.12.50.20170322-git\n"
~"Copyright (C) 2016 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"--host=i686-w64-mingw32 --target=riscv64-unknown-elf\".\nType \"show configuration\" for configuration details."
~"\nFor bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\"...\n"
~"Reading symbols from riscv-systick-blinky.elf..."
~"done.\n"
(gdb)
-data-list-register-names
This returns the following (abbreviated) output:
^done,register-names=["x0","x1","x2","x3","x4","x5","x6","x7","x8","x9","x10","x11","x12","x13","x14","x15","x16","x17","x18","x19","x20","x21","x22","x23","x24","x25","x26","x27","x28","x29","x30","x31","pc","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9","f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20","f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31","csr0","csr1","csr2","csr3","csr4","csr5","csr6","csr7","csr8","csr9","csr10","csr11","csr12","csr13","csr14","csr15","csr16","csr17","csr18","csr19","csr20","csr21","csr22","csr23","csr24","csr25","csr26","csr27","csr28","csr29","csr30","csr31","csr32","csr33","csr34","csr35","csr36","csr37","csr38",
...
"csr4051","csr4052","csr4053","csr4054","csr4055","csr4056","csr4057","csr4058","csr4059","csr4060","csr4061","csr4062","csr4063","csr4064","csr4065","csr4066","csr4067","csr4068","csr4069","csr4070","csr4071","csr4072","csr4073","csr4074","csr4075","csr4076","csr4077","csr4078","csr4079","csr4080","csr4081","csr4082","csr4083","csr4084","csr4085","csr4086","csr4087","csr4088","csr4089","csr4090","csr4091","csr4092","csr4093","csr4094","csr4095","priv","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",
...
"","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""]
As expected the names of the integer, FP, CSR, pc and priv regs are returned but for some reason these are also followed by 4162 blank register names which seems anomalous/erroneous. 4162 is the total number of actual registers - i.e. 32 integer regs + 32 FP regs + 4096 CSRs + pc + priv which may be significant?
Is this an error and, if so, how/where does it arise as I cannot see from perusing riscv-gnu-toolchain/riscv-binutils-gdb/gdb/riscv-tdep.c.
If you need any more info let me know.
Thanks
Tommy
riscv-gnu-toolchain depends on that commit, and it's not present, so it's not currently possible to checkout riscv-gnu-toolchain
Hi guys
Using the riscv-next branch of riscv-binutils-gdb (commit 9ce2a37), I noticed some strange behavior regarding addr2line on object files, although I think it is not limited to that and extends to more binutils tools that are used on object files. A word of warning, my analysis below is based on my understanding of gas, bfd and relocations, which is very limited and thus it may be completely wrong ;-)
Specifically I wanted to get the line number for an address of a previously compiled object file
riscv32-unknown-elf-addr2line -e arch.o 0x24
which outputs
/home/atraber/tmp/addr2line/arch.c:9 (discriminator 1)
The line number it reports is very far off of what I would expect (correct would be line 24).
I spent some time investigating this and it seems that the reason lies in the relocations that are being used for the dwarf2 line information contained in the object file. Specifically, the dwarf2 line information tries to advance the PC by a delta that consists of a symbol A - symbol B. This is first encoded as a BFD_RELOC_16, which then gets split into BFD_RELOC_RISCV_ADD16 and BFD_RELOC_RISCV_SUB16 by gas md_apply_fixup.
Those BFD_RELOC_RISCV_ADD16 and BFD_RELOC_RISCV_SUB16 are what we find in the object file. On a final link to an elf file, those relocation seem to be performed correctly and thus addr2line works on it, but in an object file, the final fixup has not been performed yet.
addr2line uses bfd_find_nearest_line_descriminator, which uses _bfd_dwarf2_find_nearest_line and in the end calls bfd_get_relocated_section_contents. There is no target specific macro for this function, thus bfd ends up using the generic version, which is not aware of any special handling for ADD16 and SUB16 (in contrast to riscv_elf_relocate_section).
So what happens is that the HOWTO is followed directly, and thus when the two relocations ADD16 and SUB16 are applied, instead of subtracting the 16-bit value, it just replaces it in the dwarf2 debug information (src mask is 0, after all). Since the line information should have been encoded as a delta, but now is an absolute number, the line information is completely wrong.
Since I know next to nothing about bfd and relocations, I had to give up at this point. I think the problem comes from the fact that there is no target specific implementation of bfd_elfNN_bfd_get_relocated_section_contents, but this is mostly guessing on my part. I actually don't understand why there need to be 2 separate functions (get_relocated_section_contents vs. relocate_section) to do basically the same thing.
See the attached archive for a very simple example of the problem I'm seeing.
An example can be found in save-restore.o
in libgcc
:
$ riscv32-unknown-linux-gnu-readelf -r save-restore.o
Relocation section '.rela.eh_frame' at offset 0x1158 contains 13 entries:
Offset Info Type Sym.Value Sym. Name + Addend
0000001c 00000439 R_RISCV_32_PCREL 00000000 .L0 + 0
00000020 00002023 R_RISCV_ADD32 00000030 .L0 + 0
00000020 00000427 R_RISCV_SUB32 00000000 .L0 + 0
00000068 00002139 R_RISCV_32_PCREL 00000030 .L0 + 0
0000006c 00002823 R_RISCV_ADD32 0000003c .L0 + 0
0000006c 00002127 R_RISCV_SUB32 00000030 .L0 + 0
000000b8 00002939 R_RISCV_32_PCREL 0000003c .L0 + 0
000000bc 00003c23 R_RISCV_ADD32 00000060 .L0 + 0
000000bc 00002927 R_RISCV_SUB32 0000003c .L0 + 0
0000002b 00000a35 R_RISCV_SET6 00000008 .L0 + 0
0000002b 00000834 R_RISCV_SUB6 00000006 .L0 + 0
0000003c 00001335 R_RISCV_SET6 00000016 .L0 + 0
0000003c 00001134 R_RISCV_SUB6 00000014 .L0 + 0
This isn't documented anywhere but I think by convention they are sorted by offset and in fact some tools (e.g. lld) also expects them to be sorted as well.
Not sure this is the same/related to #32. I also cannot compile on MAC OSX because of clock_gettime doesn't seem to be implemented on MAC:
/Users/megan/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/sim/riscv/sim-main.c:96:6: warning:
implicit declaration of function 'clock_gettime' is invalid in C99
[-Wimplicit-function-declaration]
if (clock_gettime (CLOCK_MONOTONIC, &ts) == 0)
^
/Users/megan/freedom-e-sdk/riscv-gnu-toolchain/riscv-binutils-gdb/sim/riscv/sim-main.c:96:21: error:
use of undeclared identifier 'CLOCK_MONOTONIC'
if (clock_gettime (CLOCK_MONOTONIC, &ts) == 0)
I am trying to work with GDB on target with no success.
see below log.
Whats the GDB project status? to what level WIP reached?
GNU gdb (GDB) 7.12.50.20170505-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "riscv64-buildroot-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /hello...done.
(gdb) b main
No registers.
(gdb) c
The program is not being run.
(gdb) info b
No breakpoints or watchpoints.
(gdb) file /hello
Load new symbol table from "/hello"? (y or n) y
Reading symbols from /hello...done.
(gdb) b main
No registers.
(gdb) run
Don't know how to run. Try "help target".
(gdb) quit
When GDB wants to make a function call while debugging, it saves registers and restores them afterwards. Currently it seems to save FPRs even if there is no F extension. Should it be checking for F before doing this? Or, what is the expected behavior here?
This is currently working on real hardware without F because OpenOCD wasn't reporting errors all the way to GDB when it accessed non-existent registers (GDB just treated whatever junk OpenOCD returned as the value, and since it didn't matter when you restored, it was fine).
We've have a branch of OpenOCD which report the errors now, so should GDB check for the presence of F before saving the FPRs (and so on as more extensions show up...), or otherwise handle errors returned for nonexistent registers? Or is returning an error to GDB for a nonexistent register the wrong thing to do?
This is a regression from riscv-binutils-2.28 (3f21b5c) to riscv-next (9fc62d5).
riscv32-unknown-linux-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux-riscv32-ilp32d.so.1 -B/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/csu/ -Wl,--version-script=/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32 -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/math -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/dlfcn -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nss -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nis -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/rt -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/resolv -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/crypt -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/mathvec -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/support -L/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nptl -Wl,-rpath-link=/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/math:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/dlfcn:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nss:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nis:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/rt:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/resolv:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/crypt:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/mathvec:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/support:/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/nptl -o /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/libc.so -T /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/shlib.lds /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/csu/abi-note.o /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf/soinit.os /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/libc_pic.os /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf/sofini.os /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf/interp.os /scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/elf/ld.so -lgcc
/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/install/bin/../lib/gcc/riscv32-unknown-linux-gnu/8.0.0/../../../../riscv32-unknown-linux-gnu/bin/ld: .eh_frame_hdr refers to overlapping FDEs.
/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/install/bin/../lib/gcc/riscv32-unknown-linux-gnu/8.0.0/../../../../riscv32-unknown-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
../Makerules:745: recipe for target '/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/libc.so' failed
make[2]: *** [/scratch/palmer/work/upstream/riscv-gnu-toolchain/build/build-glibc-linux-32/libc.so] Error 1
make[2]: Leaving directory '/scratch/palmer/work/upstream/riscv-gnu-toolchain/riscv-glibc/elf'
Makefile:215: recipe for target 'elf/subdir_lib' failed
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory '/scratch/palmer/work/upstream/riscv-gnu-toolchain/riscv-glibc'
Makefile:9: recipe for target 'all' failed
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.