riscvarchive / riscv-binutils-gdb Goto Github PK

RISC-V backports for binutils-gdb. Development is done upstream at the FSF.

License: GNU General Public License v2.0

Makefile 14.33% C 47.76% Objective-C 0.01% DIGITAL Command Language 0.02% Shell 0.54% Perl 0.11% C++ 4.38% Lex 0.21% Yacc 0.36% Emacs Lisp 0.02% D 7.22% Assembly 14.70% DTrace 9.17% Rust 0.01% Mathematica 0.01% R 0.21% Scheme 0.96% Batchfile 0.01% Common Lisp 0.01% E 0.01%

riscv-binutils-gdb's Introduction

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.

riscv-binutils-gdb's People

Stargazers

Watchers

Forkers

palmer-dabbelt darius-bluespec timsifive syntacore zizztux freebsd-riscv sifive kito-cheng ekrimer technolution fractalclone comododragon emc2 lowrisc jrrk fernandez-miguel-a michaeljclark jvarghe9998 xpack-dev-tools kuanlinchentw stuyjy lintaiwan umitsamima nitish2112 sthiruva mprc-pku firesim preacle salewski josiasmainardi runtime-scope-enforcement terudeca devurandom mit-sanctum rishikhan hstogether dayeol handsome3163 lucashmorais heshamelmatary shreyanshc zmole945 berolinux bemg p07r0457 rbarraud cmuabstract craigblackmore algochips njriasan zumbi cirromulus deepaalgochips codebeautiful pierremuller curacaoyang pentin-as jingkexu minghuadev paulyc deepabi nidalf ofershinaar keith-packard mablinov yimingyiming amedoc ladonal riscv-mcu nelson1225 l-nic stephenxi yiting16 chzchzhen npicca xcgxg 592znw jpq6699 joy2myself leileimiao patricoferris nezza dyww2 piaopiaohun yiangyang crosshairs johnwinans sjswi ndylpy666 mzguanglin andrewgbelcher blackdragonn lsnudt konf konrad-schwarz anaadi-mishra s117 openql-org hsiangkai dshud

riscv-binutils-gdb's Issues

Build failed on macOS because of missing library "rt"

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

GAS should accept fmv.x.w and fmv.w.x

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).

gdb: unimplemented breakpoint_kind_from_pc method

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.

GDB tries to access FPRs without F extension

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?

98b857eaace81a69c2dbc2ce4d59ac8eab6e63cf is missing

riscv-gnu-toolchain depends on that commit, and it's not present, so it's not currently possible to checkout riscv-gnu-toolchain

RiscV assembler - problems with 'SLLI/SRLI/SRAI' commands for RV32I

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

s_align doesn't handle 3 arguments

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

objdump: srli s0,s0,xx does not roundtrip

c.srli s0,xx is generated instead. Other registers and compressed instructions appear to be fine.

Failed to build glibc for riscv64

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

riscv64 gdb fail to operate

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?

gdb /hello

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

RiscV assembler - problem with 'SLTI' command

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

this above command hangs in bash

./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

no hang - exits normally

error: ‘scm_new_port_table_entry’ was not declared in this scope

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.

error.txt

My system configuration is as follows:
Arch Linux, gcc (GCC) 7.1.1 20170528 , GNU ld (GNU Binutils) 2.28.0.20170506

gdb can't distinguish 32- from 64-bit targets

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.

linker can not load libraries metioned in DT_NEEDED section of another library

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]

.eh_frame_hdr refers to overlapping FDEs when linking libc

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

riscv-gdb-7.10 : info locals get function variable values by using sp instead of fp (s0)

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.

Cannot build binutils on MSYS2/Windows 7- ld.info target fails

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, ld.info wasn't built at all, although there is nothing to suggest in the MinGW patches that building info files is disabled.~~ EDIT: The info files were in fact built in my compile, checking the installed files.

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.

.rela.eh_frame isn't sorted by r_offset

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.

Bad comment in elfxx-riscv.c?

@kuanlinchentw I think this comment is wrong: https://github.com/riscv/riscv-binutils-gdb/blob/riscv-next/bfd/elfxx-riscv.c#L837

How can I build 32bit riscv gdb version

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?

break dependency on Linux

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:

gettimeofday() - Yes, its time can be changed, but does this matter for simulation?
C++11 chrono library
Hack just for OS X

Are there are other constraints? Could one of the above suggestions work?

Fatal error: internal error: bad relocation #72

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;
}

Unrecognized opcode error received for fsrmi and fsflagsi

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'
$

Check the upper bits of e_flags

Simulator does not build on ARM

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.

GDB/MI -data-list-register-names returns 4162 extraneous blank reg names

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

objdump disassembly gives wrong instruction mnemonic csrrc instead of csrrci

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.

Static linked executable will segment fault on qemu after refine linker script

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)

addr2line and friends do not work correctly on relocations in object files

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.

test.tar.gz

Fails to build with guile > 2.0 installed on host

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.

_gp

riscv-binutils-gdb won't build on macos

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)

Build error: implicit declaration of function ‘CPU_MACH’

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..

Compiling the gdbserver for native riscv execution

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?

Could/should GDB/MI -data-list-register-names return ABI rather than canonical names?

Why does GDB default to using compressed breakpoint instructions for s/w BPs?

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?

riscv-next doesn't build for me

$ 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.)

Enhance assembler/disassembler output for lui/c.lui

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.

How does GDB Handle non-existent MISA?

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?

The code
https://github.com/riscv/riscv-binutils-gdb/blob/d575c2c2ba936ad70cc87038e3332b9dac5a3c16/gdb/riscv-tdep.c#L166

"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?

The readme for gdb needs to be made specific for gdb

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?

/riscv-binutils-gdb/sim/riscv/sim-main.c:93:21: error: 'CLOCK_BOOTTIME' undeclared (first use in this function) if (clock_gettime (CLOCK_BOOTTIME, &ts) == 0)

Proposed patch in #20
A more robust fix for additional OSes might be required.

Missing hideleg/hedeleg and sideleg/sedeleg CSRs

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

Dwarf Error: mangled line number section.

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;
}

gdb fails to disassemble RV64 instructions

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

can't use some gdb command such as set $pc, info registers?

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 ....

Instruction-format pseudos

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.

Should register handling be tunable to the target architecture?

wcwidth() implicit declaration of function

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?

Compilation fails on Mac OSX due to 'clock_gettime'

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)

GDB upstream code reviews

I believe this is the latest code review. I'm putting it here so it doesn't get lost

http://www.cygwin.com/ml/gdb-patches/2016-11/msg00461.html

riscvarchive / riscv-binutils-gdb Goto Github PK

riscv-binutils-gdb's Introduction

riscv-binutils-gdb's People

Stargazers

Watchers

Forkers

riscv-binutils-gdb's Issues

gdb /hello

Recommend Projects

Recommend Topics

Recommend Org

Jobs