[Bug libctf/32903] Error pointer overwritten on successful dict open in ctf_dict_open
https://sourceware.org/bugzilla/show_bug.cgi?id=32903 --- Comment #4 from Nick Alcock --- I'm piling another fix in on top of this on the v4 branch, and getting ctf_bufopen to always set its errp to 0 on success, so it always has a defined value after an open come what may. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] New: ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961
Bug ID: 32961
Summary: ".pushsection" may introduce unnecessary section
dependency which impacts "--gc-sections"
Product: binutils
Version: 2.42
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: zhiyuan.lv at linux dot intel.com
Target Milestone: ---
While compiling some Linux kernel files with "-ffunction-sections" and linker
parameter "--gc-sections", I found that several unused functions were not
removed as expected, and the root cause is unnecessary section dependencies
introduced by ".pushsection" directive. I simplified the case as below and
would like to get feedback from binutils developers of any existing workable
ways, or we could consider a new feature request to ld. Appreciate all the
input!
The case of test.c:
static inline __attribute__((always_inline)) void test_section(void)
{
asm goto(
"jmp 1f\n"
".pushsection .alt_section, \"ax\"\n"
"1:\n"
" jmp %l[t_label]\n"
".popsection\n"
: :
: : t_label);
t_label:
return;
}
void foo1(void)
{
}
void foo2(void)
{
test_section();
}
void foo3(void)
{
test_section();
}
void entry_func(void)
{
foo1();
foo3();
}
The build command: gcc test.c -ffunction-sections -Wl,-e entry_func
-Wl,--gc-sections -o test -nostdlib -O0
My environment is Ubuntu 24.04, with LD version 2.42.
The expected result is that foo2() is optimized away in generated binary by
linker, but it can still be seen with "objdump -S test".
The root cause is at ".alt_section". If we check the section dependency from
relocation table in test.o generated by "gcc test.c -c -ffunction-sections -o
test.o", foo3 has relocation entry pointing to ".alt_section" and
".alt_section" has relocation try to ".foo2", which prevents LD from removing
foo2.
If I remove the inline attribute of test_section(), the function foo2() can be
removed by linker, because relocation entry of .alt_section will not link to
foo2 or foo3. Also, if there is no "test_section()" call in foo3(), foo2() can
be removed as well.
The linker does not do anything wrong, but in my case of Linux kernel from
"_static_cpu_has()" in arch/x86/include/asm/cpufeature.h, I cannot simply
remove inline and there does not seem to be a good solution.
If all above is correct, could we consider below two options?
1. Add a new type of ".pushsection", say, ".pushnewsection", which will always
create a new section.
2. Let LD be able to ignore some given sections while doing the section
dependency calculation. If a symbol is deleted, simply remove the relocation
entry in the specified "ignored section".
Either one can address above case of test.c. Any comments? Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 Zhiyuan Lv changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-13 Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING --- Comment #3 from H.J. Lu --- Created attachment 16082 --> https://sourceware.org/bugzilla/attachment.cgi?id=16082&action=edit A patch to add --unique-pushsection Please try this. I got [hjl@gnu-tgl-3 pr32961]$ make gcc -B./ -Wa,--unique-pushsection -O2 -ffunction-sections -c -o x.o x.c ./ld -e entry_func --gc-sections -o x x.o readelf -sW x Symbol table '.symtab' contains 6 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS x.c 2: 00400160 6 FUNCGLOBAL DEFAULT1 entry_func 3: 00402000 0 NOTYPE GLOBAL DEFAULT4 __bss_start 4: 00402000 0 NOTYPE GLOBAL DEFAULT4 _edata 5: 00402000 0 NOTYPE GLOBAL DEFAULT4 _end [hjl@gnu-tgl-3 pr32961]$ readelf -SW x.o There are 25 section headers, starting at offset 0x480: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 00 00 AX 0 0 1 [ 2] .data PROGBITS 40 00 00 WA 0 0 1 [ 3] .bss NOBITS 40 00 00 WA 0 0 1 [ 4] .text.foo1PROGBITS 40 01 00 AX 0 0 16 [ 5] .text.foo2PROGBITS 48 06 00 AX 0 0 16 [ 6] .rela.text.foo2 RELA 000298 18 18 I 22 5 8 [ 7] .alt_section.text.foo1 PROGBITS 4e 05 00 AX 0 0 1 [ 8] .rela.alt_section.text.foo1 RELA 0002b0 18 18 I 22 7 8 [ 9] .text.foo3PROGBITS 58 06 00 AX 0 0 16 [10] .rela.text.foo3 RELA 0002c8 18 18 I 22 9 8 [11] .alt_section.text.foo2 PROGBITS 5e 05 00 AX 0 0 1 [12] .rela.alt_section.text.foo2 RELA 0002e0 18 18 I 22 11 8 [13] .text.entry_func PROGBITS 68 06 00 AX 0 0 16 [14] .rela.text.entry_func RELA 0002f8 18 18 I 22 13 8 [15] .alt_section.text.foo3 PROGBITS 6e 05 00 AX 0 0 1 [16] .rela.alt_section.text.foo3 RELA 000310 18 18 I 22 15 8 [17] .comment PROGBITS 73 2f 01 MS 0 0 1 [18] .note.GNU-stack PROGBITS a2 00 00 0 0 1 [19] .note.gnu.property NOTE a8 30 00 A 0 0 8 [20] .eh_frame PROGBITS d8 68 00 A 0 0 8 [21] .rela.eh_frameRELA 000328 60 18 I 22 20 8 [22] .symtab SYMTAB 000140 000138 18 23 9 8 [23] .strtab STRTAB 000278 1f 00 0 0 1 [24] .shstrtab STRTAB 000388 f1 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), D (mbind), l (large), p (processor specific) [hjl@gnu-tgl-3 pr32961]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 --- Comment #4 from H.J. Lu --- (In reply to Zhiyuan Lv from comment #2) > Thanks H.J. for the comments! > > (In reply to H.J. Lu from comment #1) > > (In reply to Zhiyuan Lv from comment #0) > > > > > > If all above is correct, could we consider below two options? > > > > > > 1. Add a new type of ".pushsection", say, ".pushnewsection", which will > > > always create a new section. > > > > This may work. Or an assembler option to force a new section for > > .pushsection. This doesn't require source code changes. Only a new > > assembler is needed. > > Yeah that would be simpler. The only concern is the side effect of always > generating new sections for .pushsection with that assembler option. Is it > OK? > We can also add .pushuniquesection. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.45 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 H.J. Lu changed: What|Removed |Added Attachment #16082|0 |1 is obsolete|| --- Comment #5 from H.J. Lu --- Created attachment 16083 --> https://sourceware.org/bugzilla/attachment.cgi?id=16083&action=edit A patch to add --unique-pushsection and .pushuniquesection Try this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 --- Comment #1 from H.J. Lu --- (In reply to Zhiyuan Lv from comment #0) > > If all above is correct, could we consider below two options? > > 1. Add a new type of ".pushsection", say, ".pushnewsection", which will > always create a new section. This may work. Or an assembler option to force a new section for .pushsection. This doesn't require source code changes. Only a new assembler is needed. > 2. Let LD be able to ignore some given sections while doing the section > dependency calculation. If a symbol is deleted, simply remove the relocation > entry in the specified "ignored section". Linker can't remove .alt_section since there is only one .alt_section and it is used by entry_func. > Either one can address above case of test.c. Any comments? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32961] ".pushsection" may introduce unnecessary section dependency which impacts "--gc-sections"
https://sourceware.org/bugzilla/show_bug.cgi?id=32961 --- Comment #2 from Zhiyuan Lv --- Thanks H.J. for the comments! (In reply to H.J. Lu from comment #1) > (In reply to Zhiyuan Lv from comment #0) > > > > If all above is correct, could we consider below two options? > > > > 1. Add a new type of ".pushsection", say, ".pushnewsection", which will > > always create a new section. > > This may work. Or an assembler option to force a new section for > .pushsection. This doesn't require source code changes. Only a new > assembler is needed. Yeah that would be simpler. The only concern is the side effect of always generating new sections for .pushsection with that assembler option. Is it OK? > > > 2. Let LD be able to ignore some given sections while doing the section > > dependency calculation. If a symbol is deleted, simply remove the relocation > > entry in the specified "ignored section". > > Linker can't remove .alt_section since there is only one .alt_section and > it is used by entry_func. Right. What I was thinking is to only remove some items in .rela.alt_section if a symbol to be removed appears in that section. Otherwise I guess linker will report error on that? "2" is a little more complicated than "1". So probably the assembler change is the way to go. Thanks! > > > Either one can address above case of test.c. Any comments? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
