Closed X547 closed 2 years ago
Maybe caused by R_RISCV_ALIGN
.
Can you share your object files with me so that I can take a look?
objects.tar.gz Link command:
mold -Bdynamic -export-dynamic -dynamic-linker /foo/bar -shared --no-undefined -o "objects/haiku/riscv64/release/system/kernel/kernel_riscv64" "objects/haiku/riscv64/release/system/kernel/cache/kernel_cache.o" "objects/haiku/riscv64/release/system/kernel/kernel_core.o" "objects/haiku/riscv64/release/system/kernel/debug/kernel_debug.o" "objects/haiku/riscv64/release/system/kernel/device_manager/kernel_device_manager.o" "objects/haiku/riscv64/release/system/kernel/disk_device_manager/kernel_disk_device_manager.o" "objects/haiku/riscv64/release/system/kernel/fs/kernel_fs.o" "objects/haiku/riscv64/release/system/kernel/messaging/kernel_messaging.o" "objects/haiku/riscv64/release/system/kernel/posix/kernel_posix.o" "objects/haiku/riscv64/release/system/kernel/slab/kernel_slab.o" "objects/haiku/riscv64/release/system/kernel/util/kernel_util.o" "objects/haiku/riscv64/release/system/kernel/vm/kernel_vm.o" "objects/haiku/riscv64/release/system/kernel/arch/riscv64/kernel_arch_riscv64.o" "objects/haiku/riscv64/release/system/kernel/platform/efi/kernel_platform_efi.o" "objects/haiku/riscv64/release/system/kernel/linkhack.so" "objects/haiku/riscv64/release/system/kernel/lib/kernel_os_main.o" "objects/haiku/riscv64/release/system/kernel/lib/arch/riscv64/kernel_os_arch_riscv64.o" "objects/haiku/riscv64/release/system/kernel/lib/kernel_lib_posix.o" "objects/haiku/riscv64/release/system/kernel/lib/arch/riscv64/kernel_lib_posix_arch_riscv64.o" "objects/haiku/riscv64/release/system/kernel/lib/kernel_misc.o" build_packages/gcc_syslibs_devel-11.2.0_2021_07_28-5-riscv64/develop/lib/libsupc++-kernel.a build_packages/gcc_syslibs_devel-11.2.0_2021_07_28-5-riscv64/develop/lib/libgcc-kernel.a --version-script=src/system/kernel/kernel_versions
objects/haiku/riscv64/release/system/kernel/arch/riscv64/kernel_arch_riscv64.o
contains an R_RISCV_ALIGN
relocation with value 14 (= 0xe) as shown below.
0000000000000188 <arch_user_thread_exit>:
188: 03800293 li t0,56
18c: 00000073 ecall
190: 8082 ret
...
19e: 0000 unimp
1a0: 0001 nop
1a0: R_RISCV_ALIGN *ABS*+0xe
1a2: 00000013 nop
1a6: 00000013 nop
1aa: 00000013 nop
So it requests the linker to align the next instruction to 14 bytes boundaries, but that's obviously wrong. I believe this is a compiler bug. What compiler are you using?
> /Haiku/data/packages/haiku2/generated.riscv64/cross-tools-riscv64/bin/riscv64-unknown-haiku-gcc --version
riscv64-unknown-haiku-gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled kernel is functional if linked with GNU ld.
If it's not too hard, please try again with gcc 12, as they might have fixed the issue already.
GCC 12 is not yet available yet. It need updating Haiku patchset.
GNU ld show no errors. Maybe not power of 2 alignment is valid? What specs says?
The spec does not say about what values are valid for R_RISCV_ALIGN
, but alignment requirements are to satisfy CPU's memory access restrictions which is naturally a power of two. I can add temporary code to mold to ignore such wrong R_RISCV_ALIGN
relocations though.
This is what GNU ld does: https://github.com/bminor/binutils-gdb/blob/a37603c43f8da7983ed53b567ea30ce66066daa2/bfd/elfnn-riscv.c#L4436.
Thanks. So, GNU ld aligns code to the next power-of-two of a given alignment (e.g. if R_RISCV_ALIGN's value is 13, it aligns the next byte to 16), but that's very odd. I believe that's also code to work-around the compiler bug.
Reported to GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172
Can you re-compile haiku/riscv64/release/system/kernel/arch/riscv64/kernel_arch_riscv64.c
with the -S
compiler option so that the compiler generates not an object file but an assembly file? Then, what is the code for arch_user_thread_exit
?
In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172, Andrew Pinski said that it might be a bug in assembler.
I localized problem file. It is arch_traps.S. Seems caused by .align 4
at beginning.
Assembler seems set R_RISCV_ALIGN value to size of NOPs in bytes.
> llvm-objdump -d objects/haiku/riscv64/release/system/kernel/arch/riscv64/arch_traps.o
objects/haiku/riscv64/release/system/kernel/arch/riscv64/arch_traps.o: file format elf64-littleriscv
Disassembly of section .text:
0000000000000000 <.text>:
0: 01 00 nop
2: 13 00 00 00 nop
6: 13 00 00 00 nop
a: 13 00 00 00 nop
000000000000000e <SVec>:
e: 2d 71 addi sp, sp, -288
10: 06 f0 sd ra, 32(sp)
12: 7e f4 sd t6, 40(sp)
14: 0e fc sd gp, 56(sp)
16: 92 e0 sd tp, 64(sp)
18: 96 e4 sd t0, 72(sp)
1a: 9a e8 sd t1, 80(sp)
1c: 9e ec sd t2, 88(sp)
1e: fa f0 sd t5, 96(sp)
20: a6 f4 sd s1, 104(sp)
22: aa f8 sd a0, 112(sp)
24: ae fc sd a1, 120(sp)
26: 32 e1 sd a2, 128(sp)
28: 36 e5 sd a3, 136(sp)
2a: 3a e9 sd a4, 144(sp)
2c: 3e ed sd a5, 152(sp)
2e: 42 f1 sd a6, 160(sp)
30: 46 f5 sd a7, 168(sp)
32: 4a f9 sd s2, 176(sp)
34: 4e fd sd s3, 184(sp)
36: d2 e1 sd s4, 192(sp)
38: d6 e5 sd s5, 200(sp)
3a: da e9 sd s6, 208(sp)
3c: de ed sd s7, 216(sp)
3e: e2 f1 sd s8, 224(sp)
40: e6 f5 sd s9, 232(sp)
42: ea f9 sd s10, 240(sp)
44: ee fd sd s11, 248(sp)
46: 72 e2 sd t3, 256(sp)
48: 76 e6 sd t4, 264(sp)
4a: 22 ea sd s0, 272(sp)
4c: 00 12 addi s0, sp, 288
4e: 22 f8 sd s0, 48(sp)
50: f3 22 10 14 csrr t0, sepc
54: 16 ee sd t0, 280(sp)
56: f3 22 00 10 csrr t0, sstatus
5a: 16 e0 sd t0, 0(sp)
5c: f3 22 20 14 csrr t0, scause
60: 16 e4 sd t0, 8(sp)
62: f3 22 30 14 csrr t0, stval
66: 16 e8 sd t0, 16(sp)
68: 0a 85 mv a0, sp
6a: 97 00 00 00 auipc ra, 0
6e: e7 80 00 00 jalr ra
0000000000000072 <SVecRet>:
72: 82 62 ld t0, 0(sp)
74: 73 90 02 10 csrw sstatus, t0
78: f2 62 ld t0, 280(sp)
7a: 73 90 12 14 csrw sepc, t0
7e: 82 70 ld ra, 32(sp)
80: a2 7f ld t6, 40(sp)
82: e2 71 ld gp, 56(sp)
84: a6 62 ld t0, 72(sp)
86: 46 63 ld t1, 80(sp)
88: e6 63 ld t2, 88(sp)
8a: 06 7f ld t5, 96(sp)
8c: a6 74 ld s1, 104(sp)
8e: 46 75 ld a0, 112(sp)
90: e6 75 ld a1, 120(sp)
92: 0a 66 ld a2, 128(sp)
94: aa 66 ld a3, 136(sp)
96: 4a 67 ld a4, 144(sp)
98: ea 67 ld a5, 152(sp)
9a: 0a 78 ld a6, 160(sp)
9c: aa 78 ld a7, 168(sp)
9e: 4a 79 ld s2, 176(sp)
a0: ea 79 ld s3, 184(sp)
a2: 0e 6a ld s4, 192(sp)
a4: ae 6a ld s5, 200(sp)
a6: 4e 6b ld s6, 208(sp)
a8: ee 6b ld s7, 216(sp)
aa: 0e 7c ld s8, 224(sp)
ac: ae 7c ld s9, 232(sp)
ae: 4e 7d ld s10, 240(sp)
b0: ee 7d ld s11, 248(sp)
b2: 12 6e ld t3, 256(sp)
b4: b2 6e ld t4, 264(sp)
b6: 52 64 ld s0, 272(sp)
b8: 42 71 ld sp, 48(sp)
ba: 73 00 20 10 sret
be: 01 00 nop
c0: 13 00 00 00 nop
c4: 13 00 00 00 nop
c8: 13 00 00 00 nop
00000000000000cc <SVecU>:
cc: 73 11 01 14 csrrw sp, sscratch, sp
d0: 2d 71 addi sp, sp, -288
d2: 06 f0 sd ra, 32(sp)
d4: 7e f4 sd t6, 40(sp)
d6: 0e fc sd gp, 56(sp)
d8: 92 e0 sd tp, 64(sp)
da: 96 e4 sd t0, 72(sp)
dc: 9a e8 sd t1, 80(sp)
de: 9e ec sd t2, 88(sp)
e0: fa f0 sd t5, 96(sp)
e2: a6 f4 sd s1, 104(sp)
e4: aa f8 sd a0, 112(sp)
e6: ae fc sd a1, 120(sp)
e8: 32 e1 sd a2, 128(sp)
ea: 36 e5 sd a3, 136(sp)
ec: 3a e9 sd a4, 144(sp)
ee: 3e ed sd a5, 152(sp)
f0: 42 f1 sd a6, 160(sp)
f2: 46 f5 sd a7, 168(sp)
f4: 4a f9 sd s2, 176(sp)
f6: 4e fd sd s3, 184(sp)
f8: d2 e1 sd s4, 192(sp)
fa: d6 e5 sd s5, 200(sp)
fc: da e9 sd s6, 208(sp)
fe: de ed sd s7, 216(sp)
100: e2 f1 sd s8, 224(sp)
102: e6 f5 sd s9, 232(sp)
104: ea f9 sd s10, 240(sp)
106: ee fd sd s11, 248(sp)
108: 72 e2 sd t3, 256(sp)
10a: 76 e6 sd t4, 264(sp)
10c: 22 ea sd s0, 272(sp)
10e: 00 12 addi s0, sp, 288
110: f3 22 00 14 csrr t0, sscratch
114: 16 f8 sd t0, 48(sp)
116: f3 22 10 14 csrr t0, sepc
11a: 16 ee sd t0, 280(sp)
11c: f3 22 00 10 csrr t0, sstatus
120: 16 e0 sd t0, 0(sp)
122: f3 22 20 14 csrr t0, scause
126: 16 e4 sd t0, 8(sp)
128: f3 22 30 14 csrr t0, stval
12c: 16 e8 sd t0, 16(sp)
12e: 03 32 04 00 ld tp, 0(s0)
0000000000000132 <.L0 >:
132: 97 02 00 00 auipc t0, 0
136: 93 82 02 00 mv t0, t0
13a: 73 90 52 10 csrw stvec, t0
13e: 0a 85 mv a0, sp
140: 97 00 00 00 auipc ra, 0
144: e7 80 00 00 jalr ra
0000000000000148 <SVecURet>:
148: 73 10 04 14 csrw sscratch, s0
000000000000014c <.L0 >:
14c: 97 02 00 00 auipc t0, 0
150: 93 82 02 00 mv t0, t0
154: 73 90 52 10 csrw stvec, t0
158: 82 62 ld t0, 0(sp)
15a: 73 90 02 10 csrw sstatus, t0
15e: 06 62 ld tp, 64(sp)
160: f2 62 ld t0, 280(sp)
162: 73 90 12 14 csrw sepc, t0
166: 82 70 ld ra, 32(sp)
168: a2 7f ld t6, 40(sp)
16a: e2 71 ld gp, 56(sp)
16c: a6 62 ld t0, 72(sp)
16e: 46 63 ld t1, 80(sp)
170: e6 63 ld t2, 88(sp)
172: 06 7f ld t5, 96(sp)
174: a6 74 ld s1, 104(sp)
176: 46 75 ld a0, 112(sp)
178: e6 75 ld a1, 120(sp)
17a: 0a 66 ld a2, 128(sp)
17c: aa 66 ld a3, 136(sp)
17e: 4a 67 ld a4, 144(sp)
180: ea 67 ld a5, 152(sp)
182: 0a 78 ld a6, 160(sp)
184: aa 78 ld a7, 168(sp)
186: 4a 79 ld s2, 176(sp)
188: ea 79 ld s3, 184(sp)
18a: 0e 6a ld s4, 192(sp)
18c: ae 6a ld s5, 200(sp)
18e: 4e 6b ld s6, 208(sp)
190: ee 6b ld s7, 216(sp)
192: 0e 7c ld s8, 224(sp)
194: ae 7c ld s9, 232(sp)
196: 4e 7d ld s10, 240(sp)
198: ee 7d ld s11, 248(sp)
19a: 12 6e ld t3, 256(sp)
19c: b2 6e ld t4, 264(sp)
19e: 52 64 ld s0, 272(sp)
1a0: 42 71 ld sp, 48(sp)
1a2: 73 00 20 10 sret
...
1ae: 00 00 unimp
> llvm-readelf -W -r objects/haiku/riscv64/release/system/kernel/arch/riscv64/arch_traps.o
Relocation section '.rela.text' at offset 0x320 contains 14 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 000000000000002b R_RISCV_ALIGN e
000000000000006a 0000000700000012 R_RISCV_CALL 0000000000000000 STrap + 0
000000000000006a 0000000000000033 R_RISCV_RELAX 0
00000000000000be 000000000000002b R_RISCV_ALIGN e
0000000000000132 0000000600000017 R_RISCV_PCREL_HI20 000000000000000e SVec + 0
0000000000000132 0000000000000033 R_RISCV_RELAX 0
0000000000000136 0000000400000018 R_RISCV_PCREL_LO12_I 0000000000000132 .L0 + 0
0000000000000136 0000000000000033 R_RISCV_RELAX 0
0000000000000140 0000000700000012 R_RISCV_CALL 0000000000000000 STrap + 0
0000000000000140 0000000000000033 R_RISCV_RELAX 0
000000000000014c 0000000900000017 R_RISCV_PCREL_HI20 00000000000000cc SVecU + 0
000000000000014c 0000000000000033 R_RISCV_RELAX 0
0000000000000150 0000000500000018 R_RISCV_PCREL_LO12_I 000000000000014c .L0 + 0
0000000000000150 0000000000000033 R_RISCV_RELAX 0
I clearly misunderstood what R_RICSV_ALIGN should behave, though it's exact behavior wasn't documented in the psABI. I implemented a correct behavior in the above patch.
Haiku kernel link and run fine now. Thanks.
gcc (2021_07_28) 11.2.0