[Bug ld/30590] New: Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590
Bug ID: 30590
Summary: Section matching broken by prefix tree change
(b1eecf6f66a4a642)
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: andrewoates at gmail dot com
Target Milestone: ---
I have a basic linker script that stopped working after upgrading to
binutils 2.40. I did a git bisect on the repository and it seems that
the breakage starts with commit
b1eecf6f66a4a642f4cb35688213e6c1c1ffdc79.
My simplified test case is as follows:
#
$ cat test1.c
int func3(void);
int func1(void) { return func3(); }
$ cat test2.c
int func1(void);
int func2(void) { return func1(); }
$ (127) cat test3.c
int func3(void) { return 0; }
$ cat linker.ld
ENTRY (func2)
SECTIONS
{
. = 0x1000;
.init-text ALIGN(4) :
{
lib1.a(*)
}
. = 0xc000;
.text ALIGN(4) :
{
*(.text)
}
}
If you then run
$ ${LD} --version
GNU ld (GNU Binutils) 2.39.50.20221130
Copyright (C) 2022 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) a later version.
This program has absolutely no warranty.
$ ar cr lib1.a test1.o test2.o
$ ar cr lib2.a test3.o
$ ${LD} -o out.bin -T linker.ld lib1.a lib2.a
$ objdump -x out.bin | grep func
c01e g F .text 000a func3
c00f g F .text 000f func1
c000 g F .text 000f func2
you see that func1 and func2 are in .text rather than .init-text where
they should be.
Running it compiled at 50be5d11289, you get the expected result:
$ objdump -x out.bin | grep func
c000 g F .text 000a func3
1000 g F .init-text 000f func1
100f g F .init-text 000f func2
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #2 from Andrew Oates --- Thanks! I have tested the linked patch and confirmed it fixes building with my original linker script and my testcase. One of the reasons I didn't realize the archive syntax was the right approach is that path matching behavior seems to be different between the undocumented form I've been using, and the proper archive form --- again, I don't totally understand the nuance, but in the testcase, if I move lib1.a into a subdirectory, "lib.a(*)" matches (pre 2.39, and with this patch), while "lib1.a:(*)" and "lib1.a:*(*)" _don't_ match (but "*/lib1.a:(*)" and variants do). That is surprising to me, but AFAICT is unrelated to this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #6 from Andrew Oates --- Thank you for the detailed explanation and quick fix! Agreed, relying on this behavior (undocumented, subtle) is suboptimal --- I'll update my linker scripts to be explicit on archive and path matching, that is a much better approach. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32705] New: RISC-V: objdump prints .insn due to incorrect $x mapping symbol handling
https://sourceware.org/bugzilla/show_bug.cgi?id=32705
Bug ID: 32705
Summary: RISC-V: objdump prints .insn due to incorrect $x
mapping symbol handling
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: andrewoates at gmail dot com
Target Milestone: ---
Symptom: objdump will fail to decode instructions when disassembling a file
generated by LLVM that mixes architecture strings between sections. This can
result in many ".insn" lines.
Root cause: LLVM emits "$x" mapping symbols to signal transitions from a custom
architecture string (such as one that does not include the "c" extension) back
to the default. When objdump sees a bare "$x" (as opposed to a "$xrv..." that
includes the architecture string), it does not actually reset to the ELF file
default. This causes subsequent instructions to be decoded based on whatever
the last-seen architecture string was.
AFAICT, gas will never emit object files like this, because it always emits a
full mapping string ("$xrv...") at the start of each section (see
gas/config/tc-riscv.c:624 [1]). LLVM's assembler will, however.
Alternatively, it's possible this is a strange interaction between LLVM's
output and ld when linking gas-generated and LLVM-generated object files
together --- but I think this is really an objdump bug.
I have a patch prepared to fix this, but filing the bug for reference. I'm
still working on a test case (which has to have a binary object file,
unfortunately, as gas won't generate a symbol sequence that triggers this bug).
Simple test case:
$ cat asm.s
.attribute arch, "rv64i"
.section .text, "ax"
addia0, zero, 1 # $xrv64i
$ cat test.c
int func(int x) { return x + 1; }
$ ../gas/as-new -o /tmp/test.o asm.s
$ clang -c -O1 -target riscv64 -o /tmp/test2.o test.c
$ ../ld/ld-new /tmp/test.o /tmp/test2.o -o /tmp/linked.o
../ld/ld-new: warning: cannot find entry symbol _start; defaulting to
000100e8
$ ../binutils/objdump -d /tmp/linked.o| less
fix-riscv-objdump () U
/tmp/linked.o: file format elf64-littleriscv
Disassembly of section .text:
000100e8 :
100e8: 00100513li a0,1
000100ec :
100ec: 2505.insn 2, 0x2505
100ee: 8082.insn 2, 0x8082
If you alter asm.s to say "rv64ic", then you get the expected disassembly at
the end:
000100ec :
100ec: 2505addiw a0,a0,1
100ee: 8082ret
[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-riscv.c;h=493c393f5b2730fe8f841da074fa106d655ec9a7;hb=HEAD#l624
--
You are receiving this mail because:
You are on the CC list for the bug.
