Closed galak closed 5 years ago
I need a testcase to reproduce. A zephyr git commit id and the make commands you used might be enough to reproduce.
Zephyr commit: https://github.com/zephyrproject-rtos/zephyr/commit/a8b208aff77fddd4e02589ed00323a0921a7d77c
samples/subsys/logging/logger/prj.conf
as follows:
diff --git a/samples/subsys/logging/logger/prj.conf b/samples/subsys/logging/logger/prj.conf
index 900df40fc8..1e4e748f27 100644
--- a/samples/subsys/logging/logger/prj.conf
+++ b/samples/subsys/logging/logger/prj.conf
@@ -4,3 +4,4 @@ CONFIG_LOG_BUFFER_SIZE=2048
CONFIG_LOG_PRINTK=y
CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=0
CONFIG_COVERAGE=n
+CONFIG_RISCV_GENERIC_TOOLCHAIN=y
Short version:
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/<PATH>/riscv-none-elf-
cd <ZEPHYR_ROOT>
source zephyr-env.sh
cd samples/subsys/logging/logger
mkdir build
cd build
cmake -DBOARD=rv32m1_vega_ri5cy ..
make
Detailed getting started guide: https://docs.zephyrproject.org/latest/getting_started/index.html
Tested with -march=[rv32ic|rv32imc|rv32ima|rv32imac] -mabi=ilp32
can't reproduced? could you provide more detail such as which gcc or binutils you are using, and the configuration of gcc (gcc -v
) or riscv-gnu-toolchain?
gcc: https://github.com/riscv/riscv-gcc/commit/bdf3ad8996cb305a822feb1eb11235e08fe4b974 binutils: https://github.com/riscv/riscv-binutils-gdb/commit/009b05a9c3c723d184f6fcda4aabdc84ef678146
riscv-gnu-toolchain configuration:
riscv-gnu-toolchain/configure --with-arch=[rv32ic|rv32imc|rv32ima|rv32imac] --enable-gcc-checking --disable-multilib
So I used riscv-gnu-toolchain
@ 7833a53f8b0d0edb2bec0bb9a177685ae75570d5 and binutils @ 009b05a9c3c723d184f6fcda4aabdc84ef678146. I built:
./configure --with-arch=rv32ima --with-abi=ilp32
I also see this with the Zephyr SDK tool set which is based on the patches from the riscv-gnu-toolchain repo.
Linux binary package:
https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.10.2/zephyr-sdk-0.10.2-setup.run
Oh, Ok, I can reproduce now, thanks!
Reduce case: https://drive.google.com/file/d/1FVwboQ72pzU0jcEAGT5zsWQlrJioBok1/view?usp=sharing
$ make
riscv32-unknown-elf-ld -melf32lriscv -o zephyr_prebuilt.elf -u _OffsetAbsSyms -u _ConfigAbsSyms -L . empty_file.c.obj -T linker.cmd --whole-archive libapp.a libzephyr.a liblib__libc__minimal.a libboards__riscv__rv32m1_vega.a libdrivers__gpio.a libdrivers__serial.a --no-whole-archive libkernel.a offsets.c.obj -lgcc --gc-sections --sort-common=descending --sort-section=alignment -X -N --orphan-handling=warn
libapp.a(ext_log_system_adapter.c.obj): in function `ext_log_system_log_adapt':
/scratch/kitoc/zephyr/samples/subsys/logging/logger/src/ext_log_system_adapter.c:36:(.text.ext_log_system_log_adapt+0x0): relocation truncated to fit: R_RISCV_RVC_LUI against `log_handler'
Makefile:5: recipe for target 'all' failed
I managed to reproduce after spending a lot of time resolving tools dependencies. But too late to do anything useful. Meanwhile, Kito extracted a testcase, so I'm using that for now. Adding --noinhibit-exec to the link, and using objdump, I see the problem function is
0000083e
This was originally
00000000
And the target function in the linker output is
000007fc
So the apparent problem here is that the target address starts above 0x1000 and is valid for c.lui, and then as relaxation proceeds it drops below 0x1000 and is no longer valid for c.lui. It looks like we can fix this by converting the c.lui to a c.li. We already do something similar for weak function support.
Also note that this requires code linked to an address of zero. Rocket-chip derived parts that I am familiar with don't put memory at 0, so won't trigger this problem. This is probably why it didn't turn up in our testing. The executable incidentally has
00000000 <__irq_wrapper>: 0: 7159 addi sp,sp,-112
and an accidental null pointer write will overwrite that, damaging that function.
That should be 0x800 not 0x1000 above. Since we use lui/addi, 0x800 is lui 0x1/addi -0x800. The symbol in question is exactly 0x800 on the first pass through which is OK for c.lui, and then ends up as 0x7fc at the end which is not OK.
I have a proposed fix, which is to use c.li instead of c.lui when this happens. It works OK on the testcase. I now get
0000083e
The fprintf is for testing purposes; I suspect this won't trigger in my usual testing. This needs to come out before the patch goes upstream. The patch also needs a linker testcase which I haven't written yet.
LGTM.
On Wed, Aug 14, 2019 at 3:49 PM Jim Wilson notifications@github.com wrote:
That should be 0x800 not 0x1000 above. Since we use lui/addi, 0x800 is lui 0x1/addi -0x800. The symbol in question is exactly 0x800 on the first pass through which is OK for c.lui, and then ends up as 0x7fc at the end which is not OK.
I have a proposed fix, which is to use c.li instead of c.lui when this happens. It works OK on the testcase. I now get
0000083e
: 83e: 4501 li a0,0 840: 7fc00513 li a0,2044 844: b725 j 76c The fprintf is for testing purposes; I suspect this won't trigger in my usual testing. This needs to come out before the patch goes upstream. The patch also needs a linker testcase which I haven't written yet.
relax-clui-to-lui.txt https://github.com/riscv/riscv-binutils-gdb/files/3503608/relax-clui-to-lui.txt
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-binutils-gdb/issues/173?email_source=notifications&email_token=AAH3XQSRYAHSI7KN4DDXGLDQESDYJA5CNFSM4ILFDKS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KKZFY#issuecomment-521448599, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH3XQQ4XRLH3YLU5YFKW43QESDYJANCNFSM4ILFDKSQ .
Can verify this fixes the issue and doesn't cause any new ones for RISC-V support in Zephyr.
Patch committed upstream.
Seeing the following:
If I drop these commits seems to link ok: https://github.com/riscv/riscv-binutils-gdb/commit/009b05a9c3c723d184f6fcda4aabdc84ef678146 https://github.com/riscv/riscv-binutils-gdb/commit/7de6f82c36c93f4ea8ec5cbf7bb0a5f636ffb045