[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #26 from Fangrui Song ---
(In reply to Andreas Schwab from comment #25)
> https://inbox.sourceware.org/binutils/87a5hjmq7r@linux-m68k.org/
Thanks.
https://inbox.sourceware.org/binutils/73460160-a0bf-48d9-84b0-c531317d0...@suse.com/
has some discussion.
97: cfi_pop 97b - \unwind, 0xe, 0x0
6ae8a30d44f016cafb46a75843b5109316eb1996 ("gas: have scrubber retain more
whitespace") caused the breakage.
This case could be handled if we gas recognizes binary operators like `-`.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/32082] gas arm aarch64: missing mapping symbols $d in the absence of alignment directives
https://sourceware.org/bugzilla/show_bug.cgi?id=32082 Fangrui Song changed: What|Removed |Added Target||arm*-*-* aarch64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32082] New: gas arm aarch64: missing mapping symbols $d in the absence of alignment directives
https://sourceware.org/bugzilla/show_bug.cgi?id=32082
Bug ID: 32082
Summary: gas arm aarch64: missing mapping symbols $d in the
absence of alignment directives
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Data sections without alignment directives (excluding
BSS) might lack '$d' symbols, and mixing data and text sections can
introduce state transition problems.
The relevant code was modified by
https://sourceware.org/pipermail/binutils/2015-March/088214.html
% cat x.c
char var = 1;
char arr[2] = {1};
% arm-linux-gnueabi-gcc -c -fdata-sections x.c && objdump -t x.o #
aarch64-linux-gnu-gcc is similar
x.o: file format elf32-little
SYMBOL TABLE:
ldf *ABS* x.c
ld .text .text
ld .data .data
ld .bss .bss
ld .data.var .data.var
ld .data.arr .data.arr
l .data.arr $d
...
LLVM integrated assembler's AArch32 port doesn't insert '$d' unless
code is present, which could lead to similar issues.
(https://reviews.llvm.org/D30724)
% clang -c --target=armv7-linux-gnueabi -fdata-sections x.c && objdump -t x.o
x.o: file format elf32-little
SYMBOL TABLE:
ldf *ABS* x.c
g O .data.var 0001 var
g O .data.arr 0002 arr
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #24 from Fangrui Song --- (In reply to H.J. Lu from comment #6) > It also breaks GCC builds for ARM, AVR, PRU and others. Do you have links to the potentially brittle assembly? In the gcc repo, I checked a few `rg '\.macro' -g '*.s' -g '*.S'` occurrences, but I did not find anything. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #23 from Fangrui Song --- (In reply to H.J. Lu from comment #0) > [...] > failed to build Linux kernel 6.10.4: > [...] > make[5]: *** [scripts/Makefile.build:362: arch/x86/crypto/sha256-avx2-asm.o] > Error 1 I have created a Linux kernel patch to fix arch/x86/crypto/sha256-avx2-asm.S https://lore.kernel.org/all/20240814044802.1743286-1-mask...@google.com/T/#u M a + b => M (a + b) Further investigation reveals that arch/arm64/kvm/hyp/nvhe/../hyp-entry has the following `(1 << 15) | 1` pattern, which was broken by the scrubber changes. (make -skj"$(nproc)" O=/tmp/linux/arm64 ARCH=arm64 LLVM=1 defconfig all) altinstruction_entry 661f, kvm_patch_vector_branch, (1 << 15) | 1, 662f-661f, 0 I have checked how the LLVM integrated assembler (which doesn't have a whitespace scrubber) handles x86 `a + b` and arm64 `(1 << 15) | 1`. After parsing `a`, it checks whether the next token is an operator, and if yes, parse the next token and merge them into `a`. https://github.com/llvm/llvm-project/commit/055006475e22014b28a070db1bff41ca15f322f0#diff-e6bafec46d3db78a4169cfe729e3852b72cf7eebe7d5cbab12b1d7e3cb00b6e8R1578 (In reply to Jan Beulich from comment #5) > (In reply to Andreas Schwab from comment #4) > > $ cat svml_d_acos2_core-sse2.S > > #define JUMPTARGET(name) *name##@GOTPCREL(%rip) > > > > .macro WRAPPER_IMPL_SSE2 callee > > call JUMPTARGET(\callee) > > .endm > > .text > > WRAPPER_IMPL_SSE2 acos > > Which cpp expands to > > .macro WRAPPER_IMPL_SSE2 callee > call *\ callee@GOTPCREL(%rip) > .endm > .text > WRAPPER_IMPL_SSE2 acos > > Wow. Where's the blank coming from? I didn't know the pre-processor may > insert random whitespace. And the pre-processed result is identical to that > of the (imo) bogus > > call JUMPTARGET(\ callee) > > How's the consumer supposed to be telling apart which one it was originally? > > Yet then documentation is unclear on whether there may be whitespace between > the \ and the parameter name. We could of course make macro expansion skip > whitespace when a valid parameter name follows. Yet I fear there could be > other anomalies as a result. In the clang -E expansion, there is no such space... .macro WRAPPER_IMPL_SSE2 callee call *\callee@GOTPCREL(%rip) .endm .text WRAPPER_IMPL_SSE2 acos But I am amused by this behavior (\ callee). .macro foo a // clang reports an error while gas currently accepts this call \ a .endm foo ab (In reply to Maciej W. Rozycki from comment #22) > (In reply to Michael Matz from comment #20) > > I don't have a good solution, I see only hacks (e.g. above: fix _this_ very > > instance of '(1) (2)' being pasted, to not be anymore, or alternatively to > > continue pasting them, but handle outermost ')' as additional macro argument > > separator). :-( > > > > Or: accept the fact that '(1) (2)' is a single macro argument, even if > > surprising. > Fair enough. Would it help and work if we at least only permitted one > kind of separator per invocation, i.e. if there's an unquoted comma in > the argument string then it becomes the separator and whitespace is not? I think this will be useful. We could explore additional opportunities to restrict space separators to as few scenarios as possible (as long as not used in the wild)... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31955] gas: Extend .loc directive to emit a label
https://sourceware.org/bugzilla/show_bug.cgi?id=31955 Fangrui Song changed: What|Removed |Added CC||jbeulich at suse dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31955] gas: Extend .loc directive to emit a label
https://sourceware.org/bugzilla/show_bug.cgi?id=31955 --- Comment #1 from Fangrui Song --- Perhaps call this .loc_label , since .cfi_label (2015) is available. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31955] New: gas: Extend .loc directive to emit a label
https://sourceware.org/bugzilla/show_bug.cgi?id=31955 Bug ID: 31955 Summary: gas: Extend .loc directive to emit a label Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- I have noticed that Meta Platforms folks have a proposal to extend the .loc directive https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608 For your convenience, the gas documentation is at https://sourceware.org/binutils/docs/as/Loc.html > The .loc directive will add a row to the .debug_line line number matrix > corresponding to the immediately following assembly instruction. Here is my summary of their proposal: Clang will add a new debug mode to emit a DW_AT_LLVM_stmt_sequence attribute to each DW_TAG_subprogram DIE, referencing the start of a line number program sequence associated with the subprogram. ``` main: .loc 0 1 13 debug_line_label .Lmain_line_entries ... .section .debug_info,"",@progbits ... .byte 14 # Abbrev [14] DW_TAG_subprogram ... .long .Lmain_line_entries - .lline_table_start0# DW_AT_LLVM_stmt_sequence .section.debug_line,"",@progbits # generated # Conceptually, the .Lmain_line_entries label is emitted at start of a line number program sequence associated with `main` ``` Advantages. *Faster symbolization* Traditional address symbolization involves locating the DW_TAG_compile_unit DIE and parsing the line number program from the DW_AT_stmt_list offset. This process requires skipping unrelated DW_TAG_subprogram DIEs. The DW_AT_LLVM_stmt_sequence attribute directly points to the relevant line number program sequence, eliminating unnecessary steps. *Improved ICF disambiguating* Identical Code Folding (ICF) can make two line number program sequences (associated with folded subprograms) indistinguishable. While DW_AT_LLVM_stmt_sequence doesn't resolve this, it identifies the associated function. If the caller is known, this additional information could help disambiguate the correct sequence. --- ELF/COFF -fno-function-sections and Mach-O .subsections_via_symbols allow consecutive functions to share the same line number program sequence. To utilize DW_AT_LLVM_stmt_sequence better, the sequences should be split to resemble ELF/COFF -ffunction-sections. Mach-O doesn't have -ffunction-sections -fno-function-sections differences and normally needs very few relocations for .debug_line and the new mode will introduce more like ELF/COFF -ffunction-sections. (On ELF, the relocation overhead can be addressed by adopting CREL https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf ) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31688] ld: Add CLASS to allow separate section matching and referring
https://sourceware.org/bugzilla/show_bug.cgi?id=31688 --- Comment #2 from Fangrui Song --- lld/ELF plans to add CLASS: https://github.com/llvm/llvm-project/pull/95323 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31884] New: Compressed .strtab and .symtab
https://sourceware.org/bugzilla/show_bug.cgi?id=31884 Bug ID: 31884 Summary: Compressed .strtab and .symtab Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- In ELF executables and DSOs, .symtab and .strtab sections can consume a significant portion of the file size (10+% or even 20+%). In many scenarios, we cannot remove them due to symbolizers (crash reporters, Linux perf, etc) and other analysis tools. When .gnu_debugdata (MiniDebugInfo) is used, the separate debug files contain .symtab/.strtab. The standard SHF_COMPRESSED feature can be used with non-SHF_ALLOC sections. It’s natural to compress .symtab and .strtab. This usage doesn't need amendment to the generic ABI. * ld/objcopy: If --compress-sections (PR 27452) is supported, just specify: --compress-sections .strtab=zstd --compress-sections .symtab=zstd * BFD (nm, objdump, etc): reader support * readelf: reader support -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28812] ld: Make --compress-debug-sections=zlib parallel
https://sourceware.org/bugzilla/show_bug.cgi?id=28812 --- Comment #2 from Fangrui Song --- This is a feature request. Compressing debug sections is slow. Parallelism, even with zstd, is pretty important. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20520] ld terminated with signal 11 [Segmentation fault]
https://sourceware.org/bugzilla/show_bug.cgi?id=20520 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #3 from Fangrui Song --- A section group without any member is valid and should ideally be supported. ld before 53720c495c7c25f9b0f4bfce3269c6c8a7696522 crashed while ld versions after the commit report: `file not recognized: file format not recognized` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #65 from Fangrui Song --- > > Changing ET_DYN to ET_EXEC fulfills the address requirement but disables > > ASLR. > > Is it intentional? > > That's my understanding of reading the -Ttext-segment documentation. The > question is whether we relax the semantic to have it as a minimum address or > define it as the expected address (thus disabling ASLR as a consequence). > > I don't have a strong opinion, but currently, Linux only enforces the former > (I think it is the main reason this makes some sense) so we will need to > discuss with kernel developers the expected semantics. If there is a strong need for the address requirement (>=p_vaddr), Linux kernel and glibc have the capability to implement it. However, this alone does not justify keeping the ld hack that sets ET_EXEC for -pie -Ttext-segment=$non_zero. > -Ttext-segment=0x6000 should create a binary which is guaranteed to be > loaded at 0x6000. -Ttext-segment sets the address of the first byte of the text segment, which likely influences the p_vaddr member of a PT_LOAD segment. When e_type is ET_EXEC, this address is also the virtual address of the first memory area. However, if e_type is ET_DYN, there's no guarantee of this address, and fulfilling this request is left to the discretion of the loaders. Since ld offers the -no-pie flag, there's no need for a workaround to make -pie behave similarly. (In addition, DF_1_PIE with ET_EXEC is very odd.) If a user desires both address>=0x6000 && ASLR, this could be achieved if ET_DYN is used and loaders satisfy the address requirement. However, retaining the ET_EXEC hack in ld would prevent the fulfillment of this goal. > PIE is the only way to create a small mode executable loaded at > 0x6000. This is an oversimplification. The -mcmodel= flag imposes specific code generation restrictions that allow relocatable files to be used in certain address space layouts after linking. While it's (almost) a sufficient condition, it's not a necessary one. Achieving high-address functionality doesn't necessitate -mcmodel=large. For instance, you can use PIC symbol addressing (combining -mcmodel=small -fpie with non-preemptible symbols) to achieve the same result. If your code is larger than 2GiB, you can even use range extension thunks. https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models#x86-64-code-models Similarly, for a function call, we no longer assume that the address of the function or its PLT entry is within the ±2GiB range from the program counter, so call callee cannot be used. Actually, call callee can still be used if we implement range extension thunks in the linker, unfortunately GCC/GNU ld did not pursue this direction. > There are 2 issues with -mcmodel=large: > > 1. Since there are no -mcmodel=large run-time libraries, you can't use > -mcmodel=large > to create any meaningful binaries. > 2. -mcmodel=large performance is much slower. True. (1) is an ecosystem issue with -mcmodel=large. However, this point is unrelated to the ld ET_EXEC hack. > I think BFD can use the emulation (-m) option for this, since, for instance, > gcc will pass -maarch64linux for aarch64-linux-gnu. I don't think this is necessary. `-pie -Wl,-no-pie` works today (lld doesn't even need `--no-relax`). Therefore, there isn't a strong argument retaining the ET_EXEC hack. % gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd -Wl,--no-relax,-Ttext-segment=0x6000 -o a % ./a 0x60001139 % ./a 0x60001139 # no ASLR -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
Fangrui Song changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||i at maskray dot me
Resolution|FIXED |---
--- Comment #37 from Fangrui Song ---
I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
should not be needed.
>From https://sourceware.org/pipermail/binutils/2013-December/083381.html
> Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
> When I added -Ttext-segment=0xXXX, one goal was to load
> small model executable above 4GB on Linux/x86-64, which
> was done with -pie -Ttext-segment=0xXXX. But -pie sets
> e_type in ELF header to ET_DYN and kernel may ignore
> p_vaddr in ELF header to load ET_DYN binary at a random
> address. This patch changes ld to set e_type in ELF header
> to ET_EXEC if the first PT_LOAD segment has non-zero
> p_vaddr. If this is unacceptable as generic ELF change,
> I can make it specific to x86.
Was the intention for the following command to load the text segment at an
address >= 0x6000 ?
```
% cat a.c
#include
int main() { printf("%p\n", main); }
% gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd
-Wl,--no-relax,-Ttext-segment=0x6000 -o a
% ./a
0x60001139
% ./a
0x60001139 # no ASLR
```
Changing ET_DYN to ET_EXEC fulfills the address requirement but disables ASLR.
Is it intentional?
I added `--no-pie` to GNU ld in 2021:
https://sourceware.org/cgit/binutils-gdb/commit/?id=e8f6c2a5bab10b039a12b69a30a8248c91161e11
, with which we can do the following instead. (GNU ld also needs `--no-relax`
while lld doesn't).
```
% gcc -pie a.c -fuse-ld=bfd
-Wl,--no-pie,--no-relax,-Ttext-segment=0x6000 -o a
% ./a
0x60001139
% ./a
0x60001139
```
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31752] gas: Support \+ in .rept/.irp/.irpc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=31752 --- Comment #1 from Fangrui Song --- In the absence of the feature, there are a few ways, but none achieves great efficiency or convenience. For example, we can define a macro that expands to a sequence of strings: 0, (0+1), ((0+1)+1), (((0+1)+1)+1), ... % cat a.s .data .macro iota n, i=0 .if \n-\i .byte \i iota \n, "(\i+1)" .endif .endm iota 16 % as a.s -o a.o % readelf -x .data a.o Hex dump of section '.data': 0x 00010203 04050607 08090a0b 0c0d0e0f --- % in altmacro allows: % cat a.s .data .altmacro .macro iota n, i=0 .if \n-\i .byte \i iota \n, %(\i+1) .endif .endm iota 16 % as a.s -o a.o % readelf -x .data a.o Hex dump of section '.data': 0x 00010203 04050607 08090a0b 0c0d0e0f -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31752] gas: Support \+ in .rept/.irp/.irpc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=31752 Fangrui Song changed: What|Removed |Added CC||jbeulich at suse dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31752] New: gas: Support \+ in .rept/.irp/.irpc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=31752 Bug ID: 31752 Summary: gas: Support \+ in .rept/.irp/.irpc directives Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- (https://sourceware.org/pipermail/binutils/2024-May/134009.html RFC: Maintaining a per-macro invocation count) gas recently introduced \+ for per-macro invocation counts within .macro/.endm directives. Building on discussions at https://sourceware.org/pipermail/binutils/2024-May/134089.html , extending the feature to loop directives would be beneficial. This would allow us to replace .byte 0, 1, 2 with: .rept 3 .byte \+ .endr (.irpc i,0123456789 \i .endr) works for a loop when the count is <= 10 but is cumbersome for larger loop counts. For nested loops, \+ could indicate the outermost loop for implementation convenience. Such constructs are rare and we can rely on clear documentation. .rept 2 .rept 2 .byte \+ .endr .endr # 0 0 1 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31688] ld: Add CLASS to allow separate section matching and referring
https://sourceware.org/bugzilla/show_bug.cgi?id=31688 --- Comment #1 from Fangrui Song --- We can shorten SECTION_CLASS to CLASS as suggested by https://inbox.sourceware.org/binutils/CAEdiOyfVYNt8Sq+GGixNek-XMPZaOccx+YSd7QO7eeZy=en...@mail.gmail.com/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31688] ld: Add CLASS to allow separate section matching and referring
https://sourceware.org/bugzilla/show_bug.cgi?id=31688 Fangrui Song changed: What|Removed |Added Summary|ld: Add SECTION_CLASS to|ld: Add CLASS to allow |allow separate section |separate section matching |matching and referring |and referring -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31688] New: ld: Add SECTION_CLASS to allow separate section matching and referring
https://sourceware.org/bugzilla/show_bug.cgi?id=31688
Bug ID: 31688
Summary: ld: Add SECTION_CLASS to allow separate section
matching and referring
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
An input section description file_pattern(section_pattern) couples two
operations:
* "defining": match a subset of sections that have been been matched before
* "referring": assign them to the current output section
Roland McGrath has an idea that we can have a new syntax to separate the two
operations.
https://inbox.sourceware.org/binutils/CAB=4xhqkixyfsm1nqrbfojj6vd3tvyvk-ehb2oxm+64hf9x...@mail.gmail.com/
(https://sourceware.org/pipermail/binutils/2024-February/132344.html)
SECTIONS {
/* Traditional output section clause: */
.output1 { *(.input1) }
/* New syntax that is not an output section clause: */
SECTION_CLASS(class1) { *(.input2) }
/* Output section clause referring to SECTION_CLASS: */
.output2 {
*(.input3) /* normal section wildcard */
SECTION_CLASS(class1) /* reference to previously defined class */
*(.input4) /* normal section wildcard */
}
.output3 {
SECTION_CLASS(class1) /* reference to remainder of class not in
.output2 */
}
.output4 {
/* reference to remainder not in .output[23], sorting applied to them
*/
SORT_BY_NAME(SECTION_CLASS(class1))
}
/* This cannot match anything that went into a SECTION_CLASS and orphans
placement does not apply to them so it's an error if any
SECTION_CLASS-matched input section has not been assigned to a
previous output section. */
.output5 { *(*) }
}
This will also be useful to tidy the .text section, whose description is
currently:
.text :
{
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
*(.text.exit .text.exit.*)
*(.text.startup .text.startup.*)
*(.text.hot .text.hot.*)
*(SORT(.text.sorted.*))
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf.em. */
*(.gnu.warning)
}
We have to place .text.unlikely/.text.startup/.text.hot before .text.* as
otherwise .text.* would match all text sections and render .text patterns
no-ops.
With SECTION_CLASS, if a user wants to make
.text.unlikely/.text.startup/.text.hot output sections (gold/ld.lld -z
keep-text-section-prefix; allow a program to selectively place sections into
hugepages) and if they want to place .text.startup/.text.hot after .text, they
can use:
SECTION_CLASS(text_startup) { *(.text.startup .text.startup.*) }
SECTION_CLASS(text_hot) { *(.text.hot .text.hot.*) }
.text : { *(.text .text.*) }
.text.startup : { SECTION_CLASS(text_startup) }
.text.hot : { SECTION_CLASS(text_hot) }
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/27452] ld: Support compressing arbitrary sections (generalized --compress-debug-sections=)
https://sourceware.org/bugzilla/show_bug.cgi?id=27452
--- Comment #3 from Fangrui Song ---
The actual form I plan to use in lld is:
--compress-sections ={none,zlib,zstd}[:level]
zstd excels at scaling from low-ratio-very-fast to
high-ratio-pretty-slow. Some users prioritize speed and prefer disk read
speed, while others focus on achieving the highest compression ratio
possible, similar to traditional high-ratio codecs like LZMA.
e.g. ld.lld --compress-sections '.debug_*=1'
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31567] New: gas/ld: Implicit addends for non-code sections
https://sourceware.org/bugzilla/show_bug.cgi?id=31567 Bug ID: 31567 Summary: gas/ld: Implicit addends for non-code sections Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- ELF defines two relocation formats, REL and RELA. REL uses implicit addends, saving space compared to RELA's explicit addend field. However, REL is often inadequate for static code relocations because the instruction to be modified (commonly 4 bytes on RISC architectures) limits the available space for the addend. GNU assembler generates RELA static relocations for most ports and generates REL for very few ones (AArch32, BPF, M32R, MIPS o32). However, using RELA can be unnecessarily bulky for data and debug sections where the constraints on addend size don't apply. I propose that we add an assembler option `-Wa,--implicit-addends-for-data` to allow non-code sections to use implicit addends to save space. In a clang -O0 -g -gpubnames build, using REL for non-code sections (sections without the SHF_EXECINSTR flag) decreased relocation size by 27.1% and the .o file size by 6.4%. Using CREL (`clang -Wa,--crel,--implicit-addends-for-data`) decreased the .o file size by 21.6%! ``` |reloc size | .o size -+---+ RELA | 550519056 | 2339938120 REL data | 401209104 | 2190607000 -Wa,--implicit-addends-for-data CREL | 44865612 | 1834284744 -Wa,--crel,--implicit-addends-for-data ``` ``` # https://github.com/MaskRay/llvm-project/tree/demo-crel clang -fuse-ld=lld -Wa,--implicit-addends-for-data a.c -o a ``` The saving is less pronounced in a non-debug -O3 build (2.3% .o file size) due to relatively fewer data relocations. ``` |reloc size | .o size -+---+--- RELA | 28235664 | 136014800 REL data | 25081480 | 132847952 CREL | 3812677 | 111591872 -Wa,--implicit-addends-for-data CREL | 3482387 | 111261704 -Wa,--crel,--implicit-addends-for-data ``` --- Technically, data sections can have static code relocations because assemblers don't reject `.data; call foo`. Since we are adding an opt-in assembler option, we can rely on the user to do the right thing and only use data directives. For a custom section, `sec->use_rela_p` is at a location matching the following stack trace. ``` perform_an_assembly_pass read_a_source_file obj_elf_section change_section subseg_force_new subseg_get bfd_make_section_anyway bfd_make_section_anyway_with_flags bfd_section_init _bfd_elf_new_section_hook ``` _bfd_elf_new_section_hook sets `sec->use_rela_p = bed->default_use_rela_p;` --- The GNU ld support for REL data relocations seems good, but .eh_frame needs to be fixed. ``` # clang is patched with my user branch mentioned by https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf#relleb-for-dynamic-relocations % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a /usr/bin/ld.bfd: .eh_frame_hdr refers to overlapping FDEs /usr/bin/ld.bfd: final link failed: bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a -fno-asynchronous-unwind-tables % ./a hello h 0x5633b227e020 0x5633b227e028 % fclang -Wa,--implicit-addends-for-data a.c b.c -fuse-ld=bfd -o a -fno-asynchronous-unwind-tables -static --target=aarch64-linux-gnu % ./a hello h 0x490050 0x490058 ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31475] binutils: Support CREL relocation format
https://sourceware.org/bugzilla/show_bug.cgi?id=31475 --- Comment #1 from Fangrui Song --- The format was tentatively named RELLEB. As I refine the original pure LEB-based format, “RELLEB” might not be the most fitting name. I have switched to SHT_CREL/DT_CREL/.crel and updated https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf https://groups.google.com/g/generic-abi/c/yb0rjw56ORw/m/eiBcYxSfAQAJ build | format | `.o size` | `size(.rel*)` | .o size decrease +-+-+---+- -O3 | RELA| 136012504 | 28235448 | -O3 | CREL| 111583312 | 3806234 | 18.0% aarch64 -O3 | RELA| 124965808 | 25855800 | aarch64 -O3 | CREL| 102529784 | 3388307 | 18.0% riscv64 -O3 | RELA| 227189744 | 91396344 | riscv64 -O3 | CREL| 149343352 | 13549699 | 34.3% -O1 -g | RELA| 1506173760 | 340965576 | -O1 -g | CREL| 1202445768 | 37237274 | 20.2% -O3 -g -gpubnames -gsplit-dwarf | RELA| 549003848 | 104227128 | -O3 -g -gpubnames -gsplit-dwarf | CREL| 459768736 | 14992114 | 16.3% -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31475] binutils: Support CREL relocation format
https://sourceware.org/bugzilla/show_bug.cgi?id=31475 Fangrui Song changed: What|Removed |Added Summary|binutils: Support RELLEB|binutils: Support CREL |relocation format |relocation format -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31475] New: binutils: Support RELLEB relocation format
https://sourceware.org/bugzilla/show_bug.cgi?id=31475 Bug ID: 31475 Summary: binutils: Support RELLEB relocation format Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- The relocation formats REL and RELA for ELF are inefficient. In a release build of Clang for x86-64, .rela.* sections consume a significant portion (approximately 20.9%) of the file size. I have developed an alternative relocation format (tentatively named RELLEB) for LLVM/Clang/lld, which yields a significant reduction of 16.7%! (.o file size) Elf32_Rel and Elf32_Rela sacrifice flexibility to maintain a smaller size, limiting relocation types to a maximum of 255. RELLEB allows 2**32 relocation types, aligning with Elf64_Rel/Elf64_Rela. --- I have analyzed many architectures including Arm (AArch32/AArch64), Power, RISC-V, MIPS, RISC-V, z/Architecture, and x86, written a detailed analysis of the size problem and my solution at https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf , created a generic ABI proposal https://groups.google.com/g/generic-abi/c/yb0rjw56ORw and an LLVM proposal https://discourse.llvm.org/t/rfc-relleb-a-compact-relocation-format-for-elf/77600 --- For binutils, we would need at least these pieces: * ld + handle SHT_RELLEB input sections + -r: copy SHT_RELLEB and rewrite + (optional; dynamic relocations) -z relleb: use .relleb.dyn instead of .rel.dyn/.rela.dyn for dynamic relocations. Can be used together with --pack-dyn-relocs=relr * readelf + -S: recognize SHT_RELLEB + -d: recognize DT_RELLEB + -r: dump SHT_RELLEB sections + (optional: if DT_RELLEB is accepted) dump DT_RELLEB table * objcopy + objcopy seems to convert SHT_REL to SHT_RELA (https://sourceware.org/bugzilla/show_bug.cgi?id=28035). If SHT_RELLEB is added, we will need to disable unneeded SHT_RELLEB => SHT_RELA conversion:) * objdump + -r: dump DT_RELLEB + -d -r: inline relocations -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27452] ld: Support compressing arbitrary sections (generalized --compress-debug-sections=)
https://sourceware.org/bugzilla/show_bug.cgi?id=27452 --- Comment #2 from Fangrui Song --- I find it very difficult to handle SHF_ALLOC sections due to data commands, range extension thunks, and other features requiring fixed-point iteration. Compressing non-SHF_ALLOC sections alone may yield a significant value, e.g. compressing .symtab and .strtab . On the lld side, I've created https://github.com/llvm/llvm-project/pull/84855 . We are debating whether the option should be named --compress-sections =[none|zlib|zstd] or --compress-nonalloc-sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31409] ld arm: global/weak non-hidden symbols referenced by R_ARM_FUNCDESC are unnecessarily exported
https://sourceware.org/bugzilla/show_bug.cgi?id=31409
--- Comment #1 from Fangrui Song ---
bfd/elf32-arm.c:16521
if (eh->fdpic_cnts.funcdesc_cnt > 0)
{
if (htab->root.dynamic_sections_created && h->dynindx == -1
&& !h->forced_local)
if (! bfd_elf_link_record_dynamic_symbol (info, h))
return false;
is too conservative. bfd_elf_link_record_dynamic_symbol records some symbols
that do not need to be exported.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31409] ld arm: global/weak non-hidden symbols referenced by R_ARM_FUNCDESC are unnecessarily exported
https://sourceware.org/bugzilla/show_bug.cgi?id=31409 Fangrui Song changed: What|Removed |Added CC||clyon at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31409] New: ld arm: global/weak non-hidden symbols referenced by R_ARM_FUNCDESC are unnecessarily exported
https://sourceware.org/bugzilla/show_bug.cgi?id=31409 Bug ID: 31409 Summary: ld arm: global/weak non-hidden symbols referenced by R_ARM_FUNCDESC are unnecessarily exported Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.s .globl _start, f0, f1 .weak f2 .protected f1 _start: f0: f1: f2: fl: bx lr .data .long f0(FUNCDESC) .long f1(FUNCDESC) .long f2(FUNCDESC) .long fl(FUNCDESC) % ./bin/as-new --fdpic a.s -o a.o && ./bin/ld-new -m armelf_linux_fdpiceabi a.o -pie -z noexecstack -o a % readelf --dyn-syms a Symbol table '.dynsym' contains 9 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 00f4 0 SECTION LOCAL DEFAULT1 .interp 2: 0204 0 SECTION LOCAL DEFAULT6 .text 3: 0208 0 SECTION LOCAL DEFAULT7 .rofixup 4: 128c 0 SECTION LOCAL DEFAULT9 .got 5: 12a0 0 SECTION LOCAL DEFAULT 10 .data 6: 0204 0 NOTYPE WEAK DEFAULT6 f2 7: 0204 0 NOTYPE GLOBAL DEFAULT6 f0 8: 0204 0 NOTYPE GLOBAL PROTECTED6 f1 In a non-FDPIC link when f0/f1/f2 are referenced by absolute relocations, f0/f1/f2 are not exported (https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#export-dynamic describes the symbol export rule). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31408] New: ld arm: fdpic link segfaults on R_ARM_GOTOFFFUNCDESC referencing a hidden symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=31408
Bug ID: 31408
Summary: ld arm: fdpic link segfaults on R_ARM_GOTOFFFUNCDESC
referencing a hidden symbol
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
__attribute__((visibility("hidden"))) void fun_hidden();
void *fun_hidden_addr() { return fun_hidden; }
% ./bin/ld-new -m armelf_linux_fdpiceabi a.o
[1]3819239 segmentation fault ./bin/ld-new a.o
% ./bin/ld-new -m armelf_linux_fdpiceabi -shared a.o
./bin/ld-new: BFD (GNU Binutils) 2.42.50.20240224 internal error, aborting at
../../../bfd/elf32-arm.c:16466 in allocate_dynrelocs_for_symbol
./bin/ld-new: Please report this bug.
If fun_hidden is defined, -shared will suceed while -no-pie still segfaults.
(gdb) bt
#0 allocate_dynrelocs_for_symbol (h=0x557d5430, inf=0x557acf80
) at ../../../bfd/elf32-arm.c:16474
#1 0x556e6892 in bfd_link_hash_traverse
(htab=htab@entry=0x557d4950, func=func@entry=0x556f8ba0
, info=info@entry=0x557acf80 ) at
../../../bfd/linker.c:674
#2 0x5570dc8b in elf_link_hash_traverse (info=0x557acf80
, f=0x556f8ba0 ,
table=0x557d4950) at ../../../bfd/elf-bfd.h:787
#3 elf32_arm_size_dynamic_sections (output_bfd=0x557d2830,
info=0x557acf80 ) at ../../../bfd/elf32-arm.c:16986
#4 0x55738ba9 in bfd_elf_size_dynamic_sections (output_bfd=, soname=, rpath=rpath@entry=0x0, filter_shlib=0x0,
audit=audit@entry=0x0, depaudit=0x0, auxiliary_filters=0x0, info=0x557acf80
,
sinterpptr=0x7fffd388) at ../../../bfd/elflink.c:7488
#5 0x556d803b in ldelf_before_allocation (audit=,
depaudit=, default_interpreter_name=0x0) at
../../../ld/ldelf.c:1839
#6 0x556bfb9b in lang_process () at ../../../ld/ldlang.c:8423
#7 0x556c4680 in main (argc=, argv=) at
../../../ld/ldmain.c:504
16468│ /* We only allocate one function descriptor with its associated
16469│ relocation. */
16470│ if (eh->fdpic_cnts.funcdesc_offset == -1)
16471│ {
16472│ asection *s = htab->root.sgot; / s is null
16473│
16474│ eh->fdpic_cnts.funcdesc_offset = s->size;
16475│ s->size += 8;
PR31407 is a similar bug failing on another line in
allocate_dynrelocs_for_symbol
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31408] ld arm: fdpic link segfaults on R_ARM_GOTOFFFUNCDESC referencing a hidden symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=31408 Fangrui Song changed: What|Removed |Added CC||clyon at gcc dot gnu.org Target||arm*-*-uclinuxfdpiceabi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31407] ld arm: fdpic link may have null pointer dereference in allocate_dynrelocs_for_symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=31407 Fangrui Song changed: What|Removed |Added Target||arm*-*-uclinuxfdpiceabi CC||clyon at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31407] New: ld arm: fdpic link may have null pointer dereference in allocate_dynrelocs_for_symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=31407 Bug ID: 31407 Summary: ld arm: fdpic link may have null pointer dereference in allocate_dynrelocs_for_symbol Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Noticed while investigating the behavior of .rofixup % cat a.s .globl foo foo: bx lr .data .long foo % ./bin/as-new --fdpic a.s -o a.o && ./bin/ld-new -m armelf_linux_fdpiceabi a.o -o a ./bin/ld-new: warning: a.o: missing .note.GNU-stack section implies executable stack ./bin/ld-new: NOTE: This behaviour is deprecated and will be removed in a future version of the linker [1]3777145 segmentation fault ./bin/ld-new -m armelf_linux_fdpiceabi a.o -o a (gdb) bt #0 0x556f9220 in allocate_dynrelocs_for_symbol (h=0x557d5348, inf=0x557acf80 ) at ../../../bfd/elf32-arm.c:16704 #1 0x556e6892 in bfd_link_hash_traverse (htab=htab@entry=0x557d4950, func=func@entry=0x556f8ba0 , info=info@entry=0x557acf80 ) at ../../../bfd/linker.c:674 #2 0x5570dc8b in elf_link_hash_traverse (info=0x557acf80 , f=0x556f8ba0 , table=0x557d4950) at ../../../bfd/elf-bfd.h:787 #3 elf32_arm_size_dynamic_sections (output_bfd=0x557d2830, info=0x557acf80 ) at ../../../bfd/elf32-arm.c:16986 #4 0x55738ba9 in bfd_elf_size_dynamic_sections (output_bfd=, soname=, rpath=rpath@entry=0x0, filter_shlib=0x0, audit=audit@entry=0x0, depaudit=0x0, auxiliary_filters=0x0, info=0x557acf80 , sinterpptr=0x7fffd3 68) at ../../../bfd/elflink.c:7488 #5 0x556d803b in ldelf_before_allocation (audit=, depaudit=, default_interpreter_name=0x0) at ../../../ld/ldelf.c:1839 #6 0x556bfb9b in lang_process () at ../../../ld/ldlang.c:8423 #7 0x556c4680 in main (argc=, argv=) at ../../../ld/ldmain.c:504 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31000] objcopy: add support for changing ELF symbol visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=31000 --- Comment #2 from Fangrui Song --- (In reply to Fangrui Song from comment #1) > On the llvm-objcopy side, someone proposes --set-symbol-visibility: > https://github.com/llvm/llvm-project/pull/80872 The proposal looks like: .. option:: --set-symbol-visibility = Change the visibility of a symbol to the specified type. .. option:: --set-symbols-visibility = Reads a list of symbols from and changes their visibility to the specified type. Visibility types: default, internal, hidden, protected. for ELF targets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30788] gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION
https://sourceware.org/bugzilla/show_bug.cgi?id=30788 Fangrui Song changed: What|Removed |Added CC||nsz at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31000] objcopy: add support for changing ELF symbol visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=31000 --- Comment #1 from Fangrui Song --- On the llvm-objcopy side, someone proposes --set-symbol-visibility: https://github.com/llvm/llvm-project/pull/80872 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31292] New: objcopy: add --prefix-symbols-remove
https://sourceware.org/bugzilla/show_bug.cgi?id=31292 Bug ID: 31292 Summary: objcopy: add --prefix-symbols-remove Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- objcopy supports --prefix-symbols to prefix all symbols. Perhaps --prefix-symbols-remove= can be added to remove the prefix. For example, cat > a.s <https://github.com/llvm/llvm-project/pull/79415 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31158] ld: Should --gc-sections respect RHS of a symbol assignment?
https://sourceware.org/bugzilla/show_bug.cgi?id=31158 --- Comment #2 from Fangrui Song --- Interesting. BFD's behavior depends on whether the assigned symbol is referenced. Let's enhance the test. cat > a.s < a.t as a.s -o a.o ld.lld --gc-sections a.o a.t -o a.lld ld.bfd --gc-sections a.o a.t -o a.gc.bfd ld.bfd a.o a.t -o a.nogc.bfd ld.gold --gc-sections a.o a.t -o a.gold % readelf -Ws a.nogc.bfd | grep '[xy]' Symbol table '.symtab' contains 9 entries: Num:Value Size TypeBind Vis Ndx Name 1: 00402008 0 NOTYPE GLOBAL DEFAULT2 y2 2: 00402008 0 NOTYPE GLOBAL DEFAULT2 x2 5: 00402000 0 NOTYPE GLOBAL DEFAULT2 x1 8: 00402000 0 NOTYPE GLOBAL DEFAULT2 y1 % readelf -Ws a.gc.bfd | grep '[xy]' Symbol table '.symtab' contains 8 entries: Num:Value Size TypeBind Vis Ndx Name 1: 0 NOTYPE GLOBAL DEFAULT ABS x2 4: 00402000 0 NOTYPE GLOBAL DEFAULT2 x1 7: 00402000 0 NOTYPE GLOBAL DEFAULT2 y1 x2 is non-zero in a GC link and zero in a no-GC link. There appears unusual: a live symbol's value can be very different when GC is enabled. Or, is this a clever trick to check whether a section is GCed? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31158] New: ld: Should --gc-sections respect RHS of a symbol assignment?
https://sourceware.org/bugzilla/show_bug.cgi?id=31158 Bug ID: 31158 Summary: ld: Should --gc-sections respect RHS of a symbol assignment? Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- cat > a.s < a.t echo 'PROVIDE(x = bar);' > b.t # not used, but worth testing as a.s -o a.o ld.lld --gc-sections a.o a.t -o a.lld ld.bfd --gc-sections a.o a.t -o a.bfd ld.gold --gc-sections a.o a.t -o a.gold In gold and lld, the symbol assignment `x = bar;` retains .rodata.bar while BFD doesn't: ld.bfd: removing unused section '.rodata.bar' in file 'a.o' Perhaps gold and lld's behavior make more sense? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED CC||i at maskray dot me Target Milestone|--- |2.41 Status|UNCONFIRMED |RESOLVED --- Comment #8 from Fangrui Song --- Implemented by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f1cd8b94e7c941c2a9107c1112ab2339916b8efd "RISC-V: Support subtraction of .uleb128." in 2023-05 (milestone: binutils 2.41). https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2029e13917d53d2289d3ebb390c4f40bd2112d21 (2023-10) fixed cases like .word (A + 3) - (B + 2) . GCC debug info probably doesn't emit expressions like this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865 --- Comment #5 from Fangrui Song --- (In reply to Nick Clifton from comment #4) > Created attachment 15115 [details] > Proposed patch Sorry for the late reply but the documentation and test change looks great! There is a minor typo below > +FILL (0x94K)# A hex value with a manitude suffix zero extends - > fills with 00 02 50 00 and `fills with `/`fills with:` can probably be used consistently. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31000] New: objcopy: add support for changing ELF symbol visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=31000
Bug ID: 31000
Summary: objcopy: add support for changing ELF symbol
visibility
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Recently I have been dealing with a benign multiple definition related to
compiler-rt/lib/builtins and rust-lang/compiler-builtins.
I need a workaround to convert certain symbols with hidden visibility to
default visibility.
(If you are curious, see
https://discourse.llvm.org/t/relocatable-file-definitions-shared-with-dso/74391
related to an improved linker error --no-allow-shlib-undefined)
It appears that objcopy does not provide a direct way to set symbol visibility,
but I have found a workaround:
objcopy --strip-symbol __udivmodti4 --add-symbol
__udivmodti4=.text.__udivmodti4:0,weak udivmodti4.c.o
Running this command on an archive will add __udivmodti4 to every archive
member, which is not desired. So, I needed to determine which archive member
defines __udivmodti4. I ended up implementing something like this in Bazel:
"""$(AR) x --output=$(@D)/lib $(OUTS)
for o in $(@D)/lib/*.o; do
$(NM) -gU $$o | grep -qw __udivmodti4 && $(OBJCOPY) --strip-symbol
__udivmodti4 --add-symbol __udivmodti4=.text.__udivmodti4:0,weak $$o
done
$(AR) r $(OUTS) $(@D)/lib/*.o
rm -rf $(@D)/lib"""
This is cumbersome.
Suppose you want to convert a symbol from default visibility to hidden
visibility. Unfortunately, I couldn't find a straightforward way to do it.
However, llvm-objcopy provides two extension:
# objcopy --strip-symbol __udivmodti4 --add-symbol
__udivmodti4=.text.__udivmodti4:0,weak,hidden udivmodti4.c.o # unrecognized
symbol flag `hidden'
llvm-objcopy --strip-symbol __udivmodti4 --add-symbol
__udivmodti4=.text.__udivmodti4:0,weak,hidden udivmodti4.c.o
llvm-objcopy --strip-symbol __udivmodti4 --add-symbol
__udivmodti4=.text.__udivmodti4:0,weak --new-symbol-visibility=hidden
udivmodti4.c.o
https://llvm.org/docs/CommandGuide/llvm-objcopy.html#cmdoption-llvm-objcopy-new-symbol-visibility
--new-symbol-visibility also affects `_binary_*_{start,end,size}` symbols
created by
llvm-objcopy --new-symbol-visibility hidden -I binary -B i386:x86-64 a.txt a.o
This feature request tracks these possible extensions:
* 'hidden' in --add-symbol
* --new-symbol-visibility=hidden
* An option like --set-symbol-flags that can operate on an existing symbol
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #4 from Fangrui Song --- Perhaps GNU ld can split `-z separate-code` into two options `--rosegment` and `-z separate-code`? I have some description at https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-rosegment > Separating data and code is a best practice. Therefore lld defaults to --rosegment while it defauls to `-z noseparate-code` to avoid waste. File content at the boundary of R/RX can be double mapped, which technically can be used to find ROP gadgets. However, decreasing ROP gadgets there is pretty much a secure theatre. https://isopenbsdsecu.re/mitigations/rop_removal/ is somewhat related. > But I wonder that why the alignment is not the kernel PAGESIZE(I set > PAGE_SIZE to 4096 when compiling, but the alignment is still 65535)? The protocol between the linke and the kernel is that a linked object file may run on systems with different page sizes. All page sizes not larger than MAXPAGESIZE (link-time decision) are supported. The model in practice does not build a different object file for each page size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #6 from Fangrui Song --- (In reply to Alan Modra from comment #5) > (In reply to Fangrui Song from comment #0) > > For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the > > original relocation type even if a linker optimization is applied. > > No, ppc64 adjusts relocations to match the emitted code. See for example > R_PPC64_GOT16_LO_DS handling in ppc64_elf_relocate_section, adjusted to > R_PPC64_TOC16_LO when a got indirect code sequence can be edited to got > pointer relative. > > > This is partly to communicate more information to the analysis tool > > This is exactly why relocations for ppc64 (and ppc32) were edited. IBM's > FDPR post-link optimisation tool used them. ppc64 even emits relocs for > linker generated stub code. > > The fact that other targets emit the original relocations is not a good > argument for saying that riscv should do so. Most maintainers of other > targets simply didn't see a need to correct the relocs when editing code. Thanks for the reply! I did not know. I have now made some notes on https://maskray.me/blog/2023-02-26-linker-notes-on-power-isa#emit-relocs For example, a TOC-indirect to TOC-relative optimization uses a pair of relocations `R_PPC64_TOC16_HA(.toc)+R_PPC64_TOC16_LO_DS(.toc)`. After optimization, they will become `R_PPC64_TOC16_HA(sym)+R_PPC64_TOC16_LO(sym)`. The `R_PPC64_TOC16_HA` relocation is present even if the first instruction is converted to a NOP. A general-dynamic TLS model code sequence may use relocations `R_PPC64_GOT_TLSGD16_HA+R_PPC64_GOT_TLSGD16_LO+R_PPC64_TLSGD+R_PPC64_REL24`. After optimization, they will become: * `R_PPC64_NONE+R_PPC64_TPREL16_HA+R_PPC64_TPREL16_LO+R_PPC64_NONE` after general-dynamic to local-exec TLS optimization. * `R_PPC64_GOT_TPREL16_HA+R_PPC64_GOT_TPREL16_LO_DS+R_PPC64_NONE+R_PPC64_NONE` after general-dynamic to initial-exec TLS optimization. So it seems that ppc performed conversion can all be described by existing relocation types, which is nice. However, I do not know whether the property will hold for all current and future RISC-V relaxation schemes. When investigating relocation overflow pressure for x86-64 small code model, I have found that preserving the original relocation type gives me more information: I can tell how many R_X86_64_PC32/R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are problematic. If they are converted to R_X86_64_PC32/R_X86_64_32, I'd lose some information. Perhaps whether the --emit-relocs uses the original relocation type or the transformed relocation type , does not matter for the majority of use cases. E.g. Linux kernel's objtool, seems to perform a sanity check on relocations. It just needs to know the categories of relocations, e.g. absolute/PC-relative, not the exact type. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30865] New: ld: =fillexp different behaviors for hexidecimal literal
https://sourceware.org/bugzilla/show_bug.cgi?id=30865
Bug ID: 30865
Summary: ld: =fillexp different behaviors for hexidecimal
literal
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2c382fb6f5499e01ce83c221f4b35f39e5b414f0
(Feb 2002) added support for arbitrary length fill patterns, e.g.
SECTIONS { .text : { *(.text) }=0x0102030405060708 }
A side effect possibly from this commit is that 0x literals have different
behaviors from decimal literals and expressions.
.text : { *(.text) } =0x90# set the fill pattern to 0x90909090
.text : { *(.text) } =0x90909090 # set the fill pattern to 0x90909090
.text : { *(.text) } =144 # set the fill pattern to 0x0090
.text : { *(.text) } =0x90+0 # set the fill pattern to 0x0090
This has been the case for ~20 years, so probably not worth changing, but I
felt obliged to point out this special behavior to warn users about 0x90 0x9090
0x909090 that are shorter than 4 bytes.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #2 from Fangrui Song --- (In reply to Palmer Dabbelt from comment #1) > Nelson and I are just chatting about this. It's not intentional, but we > also don't quite know what the right answer is here: there's some relocs we > can touch less (like leaving R_RISCV_ALIGN in outputs even after we've > aligned, for example) but others we'd have to avoid relaxing (like > R_RISCV_CALL, which requires two instructions). Certainly producing > binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't > be producing binaries with it. > > So I think we're happy to fix bugs here, but we really need to know what the > desired output is. > > Do you have something more concrete about what you're looking for? Thanks for looking into this. My feeling is that --emit-relocs should switch to preserve the original relocation type, including R_RISCV_CALL_PLT(etc), R_RISCV_RELAX, and R_RISCV_ALIGN. Analysis tools can check whether R_RISCV_RELAX is present in a section. If present, they need to do disassembly work to figure out whether a R_RISCV_CALL_PLT relocations is associated with an un-relaxed code sequence of a relaxed code sequence. Yes, it may look dirty but I don't think there is a better way. (x86-32 relocation handling inspects the relocated relocation as well) FWIW I left a comment on https://lore.kernel.org/linux-riscv/2023091221.zejmknzcm5mwz...@google.com/T/#t on the only --emit-relocs use I can find, which is relatively new in the Linux kernel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Fangrui Song changed: What|Removed |Added CC||jnoorman at igalia dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Fangrui Song changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com, ||kito.cheng at gmail dot com, ||nelsonc1225 at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] New: ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Bug ID: 30844 Summary: ld riscv: --emit-relocs does not retain the original relocation type Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- From https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#ld---emit-relocs (with updated instructions) For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the original relocation type even if a linker optimization is applied. This is partly to communicate more information to the analysis tool and partly because the transformation may not be described with any existing relocation type. However, the RISC-V port changes the relocation type, including relocation types for relaxable instructions (e.g. R_RISCV_CALL_PLT), and markers (R_RISCV_ALIGN and R_RISCV_RELAX). I believe this was not a deliberate decision as there is no --emit-relocs test at all in ld/testsuite/ld-riscv-elf/. So far, the unintentional change seems fine but certain relaxations (such as TLSDESC) may not have relocation types associated with the relaxed instructions. cat > aarch64.s <<'eof' .global _start; _start: adrpx1, :got:x ldr x1, [x1, #:got_lo12:x] .data; .globl x; .hidden x; x: .word 0 eof cat > ppc64.s <<'eof' .globl _start; _start: addis 3, 2, .Lhidden@toc@ha ld3, .Lhidden@toc@l(3) lwa 3, 0(3) .data; .globl hidden; .hidden hidden; hidden: .long 0 .section .toc,"aw",@progbits .Lhidden: .tc hidden[TC], hidden eof cat > x86-64.s <<'eof' .globl _start; _start: movq foo@gotpcrel(%rip), %rax foo: nop eof aarch64-linux-gnu-gcc -fuse-ld=lld -B/tmp/Rel/bin -nostdlib aarch64.s -Wl,--emit-relocs -o aarch64 && aarch64-linux-gnu-objdump -dr aarch64 | sed -E '/^\s*$/d' powerpc64le-linux-gnu-gcc -nostdlib ppc64.s -Wl,--emit-relocs -o ppc64 && powerpc64le-linux-gnu-objdump -dr ppc64 | sed -E '/^\s*$/d' gcc -nostdlib x86-64.s -Wl,--emit-relocs -o x86-64 && objdump -dr x86-64 | sed -E '/^\s*$/d' cat > riscv64.s <<'eof' .global _start; _start: call f call f .balign 8 f: ret eof riscv64-linux-gnu-gcc -nostdlib riscv64.s -Wl,--emit-relocs -o riscv64 && riscv64-linux-gnu-objdump -dr riscv64 | sed -E '/^\s*$/d' Output (removed blank lines for compacter output): ``` aarch64: file format elf64-littleaarch64 Disassembly of section .text: 000102f8 <_start>: 102f8: d503201fnop 102f8: R_AARCH64_ADR_GOT_PAGE x 102fc: 10100661adr x1, 303c8 102fc: R_AARCH64_LD64_GOT_LO12_NC x ppc64: file format elf64-powerpcle Disassembly of section .text: 0240 <_start>: 240: 00 00 00 60 nop 240: R_PPC64_TOC16_HA hidden 244: 00 81 62 38 addir3,r2,-32512 244: R_PPC64_TOC16_LO hidden 248: 02 00 63 e8 lwa r3,0(r3) x86-64: file format elf64-x86-64 Disassembly of section .text: 12dd <_start>: 12dd: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# 12e4 12e0: R_X86_64_REX_GOTPCRELXfoo-0x4 12e4 : 12e4: 90 nop riscv64: file format elf64-littleriscv Disassembly of section .text: 02a0 <_start>: 2a0: 008000efjal 2a8 2a0: R_RISCV_JALf 2a4: 004000efjal 2a8 2a4: R_RISCV_NONE *ABS*+0x4 2a4: R_RISCV_JALf 02a8 : 2a8: 8082ret 2a8: R_RISCV_NONE *ABS*+0x4 2a8: R_RISCV_NONE *ABS*+0x6 ``` I have a section "ld --emit-relocs" with very brief information on my website for a while. Recently https://reviews.llvm.org/D159082 motivated me to elaborate and bring this up:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30612] maxpagesize alignment after relro segment takes up space
https://sourceware.org/bugzilla/show_bug.cgi?id=30612 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Fangrui Song --- Unfortunately, I believe this is nearly infeasible to fix, as long as the alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout in GNU ld is very difficult. I have a short summary of different design choices: https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-relro > GNU ld uses one RW PT_LOAD program header with padding at the start. The > first half of the PT_LOAD overlaps with PT_GNU_RELRO. The padding is added so > that the end of PT_GNU_RELRO is aligned by max-page-size. (See ld.bfd > --verbose output.) Prior to GNU ld 2.39, the end was aligned by > common-page-size. GNU ld's one RW PT_LOAD layout makes the alignment increase > the file size. max-page-size can be large, such as 65536 for many systems, > causing wasted space. > > lld utilitizes two RW PT_LOAD program headers: one for RELRO sections and the > other for non-RELRO sections. Although this might appear unusual initially, > it eliminates the need for alignment padding as seen in GNU ld's layout. I > implemented the current layout in 2019 (https://reviews.llvm.org/D58892). > > The layout used by mold is similar to that of lld. In mold's case, the end of > PT_GNU_RELRO is padded to max-page-size by appending a SHT_NOBITS > .relro_padding section. This approach ensures that the last page of > PT_GNU_RELRO is protected, regardless of the system page size. However, when > the system page size is less than max-page-size, the map from the first RW > PT_LOAD is larger than needed. > > In my opinion, losing protection for the last page when the system page size > is larger than common-page-size is not at all an issue. Protecting .got.plt > is the main purpose of -z now. Protecting a small portion of .data.rel.ro > doesn't really make the program more secure, given that .data and .bss are so > huge and full of attach targets. If users are really anxious, they can set > common-page-size to match their system page size. > > I am unsure whether lld's hidden assumption about common-page-size <= system > page-size is an issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30788] gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION
https://sourceware.org/bugzilla/show_bug.cgi?id=30788 Fangrui Song changed: What|Removed |Added Target||aarch64*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30788] New: gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION
https://sourceware.org/bugzilla/show_bug.cgi?id=30788 Bug ID: 30788 Summary: gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Extracted from https://github.com/llvm/llvm-project/issues/63418 ``` cat > a.s <https://github.com/ARM-software/abi-aa/issues/217 is created to decide how we should create GOT entries, GDAT(S+A) vs GDAT(S). If the decision is to respect existing linker behaviors and allow the same GOT entry for :got_lo12:(.data+0) and :got_lo12:(.data+4), this assembler change is IMO a prerequisite. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30684] readelf -s: support an option to display section names
https://sourceware.org/bugzilla/show_bug.cgi?id=30684 --- Comment #4 from Fangrui Song --- (In reply to Nick Clifton from comment #3) > Created attachment 15016 [details] > Proposed patch > > And here is a full patch. > > After some more thought, I decided that the new behaviour needed to be gated > by a command line option, so I have added --extra-sym-info to do this. Thank you for implementing this! Yes, I think quite a few projects rely on the output of readelf -Ws. Using an opt-in option is necessary. The option name -X/--extra-sym-info looks good to me. Another long option name choice is --symbol-details to be similar to --section-details. > I have also moved the display of non-visibility related bits in the st_other > field to this new option. This means that by default the symbol table > displayed by readelf should be completely uniform. Like [: 8] in the [Other] column for ppc64 ELFv2? Looks good to me, but I'd like to hear from Alan. > I have discarded the "==>" for section symbols - it looked silly. Instead I > just filled the gap with spaces. objdump -t shows the section name twice for STT_SECTION symbols as well. I think readelf -sX displaying the section name twice should be as well, to not make STT_SECTION special. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30684] New: readelf -s: support an option to display section names
https://sourceware.org/bugzilla/show_bug.cgi?id=30684 Bug ID: 30684 Summary: readelf -s: support an option to display section names Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- I almost always prefer readelf -Ws to objdump -t for ELF symbol information as the former presents all information without distortion. Certain symbol types have strange output for objdump -t output, e.g. STT_SECTION=>'d', STT_NOTYPE=>no particular character. There is, however, one feature that objdump -t is better: it displays the section name for a symbol defined relative to a section. readelf -Ws just prints st_shndx, which is sometimes less readable. I wonder whether readelf can add an option to change the "Ndx" column to display section names instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 Fangrui Song changed: What|Removed |Added Target||x86_64-* Assignee|unassigned at sourceware dot org |i at maskray dot me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Fangrui Song --- https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5e24da908dbf6ddeb03e2b194f6b39dea3c660f3 Used PATCH v4 with a modification: https://sourceware.org/pipermail/binutils/2023-July/128334.html This is a minor feature, so I do not rush it into the upcoming binutils 2.41 release. Possible target milestone: binutils 2.42 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30623] New: objcopy --set-section-flags: support toggling a flag
https://sourceware.org/bugzilla/show_bug.cgi?id=30623 Bug ID: 30623 Summary: objcopy --set-section-flags: support toggling a flag Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- It will be more convenient if --set-section-flags supports toggling a flag, instead of specifying the full set of flags, e.g. --set-section-flags .foo=-alloc --set-section-flags .foo=-readonly --set-section-flags .foo=+readonly The lack of toggling flags is currently not so cumbersome because most ELF sections only use "alloc" and "readonly". However, if we consider more flags, e.g. "exclude", "large" (https://sourceware.org/bugzilla/show_bug.cgi?id=30592), the lack of toggling flags is quite inconvenient. For example, if we want to add SHF_X86_64_LARGE to large data sections, we need to figure out whether "readonly" is set. --set-section-flags .ldata=alloc,large --set-section-flags .lrodata=alloc,readonly,large It will be more convenient if we can just use --set-section-flags .ldata=+large --set-section-flags .lrodata=+large Candidate syntax: the right hand side of `=` can use one of the two forms: * comma separated flags, e.g. alloc,large * comma separated + flags and - flags, e.g. -alloc,+readonly Other forms like -alloc,readonly probably should be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30374] ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 --- Comment #5 from Fangrui Song --- (In reply to Nick Clifton from comment #4) > OK, I have decided to commit my patch now, so that it gets into the next > release. If there are problems we can always reopen this PR. Thank you! I have tested the feature. It looks great. > ld foo.o --remap-inputs=foo.o=bar.o > > will not rename foo.o to bar.o, [...] I hope that this will be fine. Users can get adapted to this limitation. > One other thing: I wondered if we ought to accept the "@file" syntax in the > --remap-inputs option, as a synonym for --remap-inputs-file. What do you > think ? I think no. --remap-inputs @1.map would require extra work and the syntax is probably not conventional. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 --- Comment #1 from Fangrui Song --- Patch: https://sourceware.org/pipermail/binutils/2023-June/128052.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] New: objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 Bug ID: 30592 Summary: objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Linkers may place SHF_X86_64_LARGE sections away from regular sections to alleviate relocation overflow pressure [1]. It would be nice to have the ability to add the SHF_X86_64_LARGE flag to sections in relocatable object files, especially for prebuilt object files that the user cannot control. I suggest that we allow objcopy --set-section-flags .data=alloc,large to set SHF_X86_64_LARGE. [1]: https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27452] ld: Support compressing arbitrary sections (generalized --compress-debug-sections=)
https://sourceware.org/bugzilla/show_bug.cgi?id=27452 --- Comment #1 from Fangrui Song --- I think we should just allow SHF_ALLOC | SHF_COMPRESSED sections. Created https://groups.google.com/g/generic-abi/c/HUVhliUrTG0 The proposed option syntax is: --compress-sections='.debug_*=zlib' . This applies to both SHF_ALLOC and non-SHF_ALLOC sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/16523] support xz compression of debug info files
https://sourceware.org/bugzilla/show_bug.cgi?id=16523 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Fangrui Song --- We now have --compress-debug-sections=zstd as another choice. To achieve a similar compression ratio like xz, zstd is slower to compress, but the decompression is much faster. Example: https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ says "zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30237] strip fails on riscv with 'not enough room for program headers, stgnjAlO[.interp]: bad value'
https://sourceware.org/bugzilla/show_bug.cgi?id=30237 --- Comment #7 from Fangrui Song --- (In reply to Andreas Schwab from comment #6) > Since arm32 does not have PT_ARM_ATTRIBUTES it cannot have this problem in > the first place. With the PHDRS linker script command, we can customize program headers and drop the PT_RISCV_ATTRIBUTES program header even with newer linkers that add PT_RISCV_ATTRIBUTES. At any rate, whether a non-SHF_ALLOC section like SHT_RISCV_ATTRIBUTES is covered by a PT_LOAD should not cause objcopy/strip to behave abnormally. A non-SHF_ALLOC section like SHT_RISCV_ATTRIBUTES is not commonly covered by a PT_* program header. The SHT_RISCV_ATTRIBUTES is not that different from .comment from a strip tool's viewpoint. I don't think .comment not covered by a program header allows the strip tool to behave abnormally. > If you think this program is trivial, then why does it > have .riscv.attributes? Even for the trivial program, there is some information like Attribute Section: riscv File Attributes Tag_RISCV_stack_align: 16-bytes Tag_RISCV_arch: "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0" I am concerned that RISC-V folks may add more not-so-useful attributes in the future, but this is unrelated to this bug report. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30237] strip fails on riscv with 'not enough room for program headers, stgnjAlO[.interp]: bad value'
https://sourceware.org/bugzilla/show_bug.cgi?id=30237 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- (In reply to alice from comment #4) > forwarded upstream too, then: > https://github.com/llvm/llvm-project/issues/63084 riscv-non-isa/riscv-elf-psabi-doc#71 (2021-06) added PT_RISCV_ATTRIBUTES, but no dynamic loader uses this yet. I created https://reviews.llvm.org/D152065 to add PT_RISCV_ATTRIBUTES to ld.lld. > psykose-edge-riscv64:~$ strip somebin > strip: stgnjAlO: not enough room for program headers, try linking with -N > strip: stgnjAlO[.interp]: bad value This looks like a GNU objcopy/strip bug. The tool should work regardless of whether the linker creates PT_RISCV_ATTRIBUTES. AArch32 doesn't have PT_ARM_ATTRIBUTES and I believe objcopy/strip can process such a trivial program. The RISC-V port should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30449] gas riscv: support pseudo-instruction "lga"
https://sourceware.org/bugzilla/show_bug.cgi?id=30449 Fangrui Song changed: What|Removed |Added Target||riscv*-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30449] New: gas riscv: support pseudo-instruction "lga"
https://sourceware.org/bugzilla/show_bug.cgi?id=30449 Bug ID: 30449 Summary: gas riscv: support pseudo-instruction "lga" Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- "lga" has been in riscv-asm-manual since the resolution to https://github.com/riscv-non-isa/riscv-asm-manual/issues/50 In LLVM 17, LLVM integrated assembler will support "lga". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30426] gas x86: reject {call,jmp} [offset func] in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=30426 Fangrui Song changed: What|Removed |Added Target||i686* x86_64* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30426] New: gas x86: reject {call,jmp} [offset func] in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=30426
Bug ID: 30426
Summary: gas x86: reject {call,jmp} [offset func] in Intel
syntax
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.s
call [offset func]
jmp [offset func]
% as -msyntax=intel a.s -o a.o
% objdump -M intel -dr a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
<.text>:
0: e8 00 00 00 00 call 0x5
1: R_X86_64_PLT32 func-0x4
5: e9 00 00 00 00 jmp0xa
6: R_X86_64_PLT32 func-0x4
MSVC ml64.exe reports "error A2023:instruction operand must have size"
for the following assembly listing
extrn k:proc
_text segment
call [offset k]
; call qword ptr [offset k] ; this is somehow accepted
_text ends
end
This is a patch for LLVM integrated assembler (used by `clang -c -masm=intel`,
llvm-mc, etc) to reject call [offset k] and jmp [offset k]:
https://reviews.llvm.org/D150048
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30374] ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 --- Comment #1 from Fangrui Song --- I have picked `=` as a separator a la -fdebug-prefix-map=. --remap-inputs= may be handy to specify just one pattern. Here is an example: --remap-inputs-file=1.map --remap-inputs-file=2.map --remap-inputs='d*.so=d.so' where 1.map contains aa.o=a.o b?.[b]c=b.o and 2.map contains cc.a=c.a ## Use /dev/null to indicate an input file which should be ignored. empty=/dev/null -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30374] New: ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 Bug ID: 30374 Summary: ld: Add --remap-inputs-file= to remap input files Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Hello! I'm considering an option in ld.lld to replace or remove input files with glob patterns. https://reviews.llvm.org/D148859 --remap-inputs-file= can be specified multiple times, each naming a remap file that contains from-globto-file lines or #-led comments, e.g. aa.oa.o b?.[b]c b.o cc.ac.a d*.so d.so ## Use /dev/null to indicate an input file which should be ignored. /dev/null is treated as an empty linker script. empty /dev/null This option can be used to: * replace an input file. E.g. "*/libz.so\texp/libz.so" can replace a resolved -lz without updating the input file list or (if used) a response file. When debugging an application where a bug is isolated to one single input file, this option gives an convenient way to test fixes. * remove an input file with /dev/null (changed to NUL on Windows), e.g. "a.o\t/dev/null". A build system may add unneeded dependencies. This option gives an convenient way to test the result removing some inputs. bash/zsh process substitution is handy for specifying a pattern without using a remap file, e.g. --remap-inputs-file=<(printf 'a.o\taa.o') -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27565] ld: Support input section description keyword: REVERSE
https://sourceware.org/bugzilla/show_bug.cgi?id=27565
--- Comment #3 from Fangrui Song ---
(In reply to Nick Clifton from comment #2)
> Created attachment 14772 [details]
> Proposed patch
>
> Hi Fanguri,
>
> What do you think of this patch ? Does it do what you need ?
>
> Cheers
> Nick
Hi Nick, thanks for working on this feature! Do you have some examples how this
keyword can be used? If I try
(https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/linkerscript/sort-init.s#L53):
SECTIONS {
.init_array : {
*(REVERSE(SORT_BY_INIT_PRIORITY(.init_array.* .ctors.*))
SORT_BY_INIT_PRIORITY(foo*))
*(REVERSE(.init_array .ctors))
}
}
ld reports `syntax error`.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 Fangrui Song changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #13 from Fangrui Song --- Fixed for 2.41 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27565] ld: Support input section description keyword: REVERSE
https://sourceware.org/bugzilla/show_bug.cgi?id=27565 --- Comment #1 from Fangrui Song --- Justin Cady wants to add REVERSE to ld.lld in https://reviews.llvm.org/D145381 The semantics seem pretty clear, so ld.lld adopting the feature first may be fine :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26119] ld: Support --reproduce
https://sourceware.org/bugzilla/show_bug.cgi?id=26119 Fangrui Song changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #1 from Fangrui Song --- *** Bug 30091 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30091] Bundle all artifacts and command line invocation to quickly reproduce linker errors
https://sourceware.org/bugzilla/show_bug.cgi?id=30091 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||i at maskray dot me --- Comment #1 from Fangrui Song --- Thanks for +1 on this feature request. I reported it on https://sourceware.org/bugzilla/show_bug.cgi?id=26119 as well :) In lld, the feature is also activated with an environment variable. LLD_REPRODUCE=/tmp/rep.tar gcc -fuse-ld=lld ... *** This bug has been marked as a duplicate of bug 26119 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28824] relro security issues
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 --- Comment #22 from Fangrui Song --- > [...] (psykose/alice confirmed lld does not have the problem on alpine, but I > am not sure if they do the correct thing™ here security-wise -- it's good to > have a concrete idea here) lld does the correct thing. I changed lld to adopt the two-RW-PT_LOAD approach in 2019. I have some notes about different linkers' behaviors: https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-noseparate-code and https://maskray.me/blog/2021-08-22-freebsd-src-browsing-on-linux-and-my-rtld-contribution#p_memsz-of-pt_gnu_relro (where I fixed FreeBSD rtld to do similarly to glibc/musl . Without this, I'd be very careful changing lld's common-page-size padding behavior). lld still pads p_memsz of PT_GNU_RELRO (the first RW PT_LOAD) to a common-page-size boundary instead of a max-page-size boundary. If GNU ld now uses max-page-size boundary for all ports but x86, I think https://sourceware.org/binutils/docs/ld/Builtin-Functions.html "DATA_SEGMENT_ALIGN(maxpagesize, commonpagesize)" needs a clarification: it seels that commonpagesize is ignored for most ports? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 --- Comment #9 from Fangrui Song --- rustc runs into this problem as well as it currently somehow defaults to disable R_X86_64_*GOTPCRELX/R_386_GOT32X. Since the fix is so trivial, I sent https://sourceware.org/pipermail/binutils/2023-January/125506.html https://sourceware.org/pipermail/binutils/2023-January/125507.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29847] New: objdump: add --show-all-symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29847 Bug ID: 29847 Summary: objdump: add --show-all-symbols Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- llvm-objdump 16 will have a new option --show-all-symbols (https://reviews.llvm.org/D131589) which prints all symbols during disassembly. This is useful to know all symbols defined at a location. https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-objdump/multiple-symbols.s and https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-objdump/multiple-symbols-mangling.s demonstrate the behavior. Here is some dump for your convenience. You can reproduce by yourself if you have installed llvm-mc and yaml2obj and have cloned llvm-project. cd llvm-project/llvm/test/tools/llvm-objdump llvm-mc -triple armv8a-unknown-linux -filetype=obj multiple-symbols.s -o a.o % fllvm-objdump --triple armv8a -d a.o a.o:file format elf32-littlearm Disassembly of section .text: : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr 0008 : 8: eb00 0080 add.w r0, r0, r0, lsl #2 c: 4770 bx lr % fllvm-objdump --triple armv8a --show-all-symbols -d a.o a.o:file format elf32-littlearm Disassembly of section .text: <$a.0>: : : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr 0008 <$t.1>: 0008 : 0008 : 8: eb00 0080 add.w r0, r0, r0, lsl #2 c: 4770 bx lr % fllvm-objdump --triple armv8a --disassemble-symbols= -d a.o a.o:file format elf32-littlearm Disassembly of section .text: : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr (llvm-objdump doesn't have --disassemble[=symbol]. It uses --disassemble-symbols=) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29823] ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=29823 Fangrui Song changed: What|Removed |Added CC||kito.cheng at gmail dot com, ||nelson.chu at sifive dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29823] New: ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=29823 Bug ID: 29823 Summary: ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.s .attribute 9, "0" % riscv64-linux-gnu-gcc -c a.s % ~/Dev/binutils-gdb/out/riscv64/ld/ld-new a.o a.o [1]3982286 segmentation fault ~/Dev/binutils-gdb/out/riscv64/ld/ld-new a.o a.o lang_check=>_bfd_riscv_elf_merge_private_bfd_data=>riscv_merge_attributes => `result &= _bfd_elf_merge_unknown_attribute_low (ibfd, obfd, i);` => `get_elf_backend_data (err_bfd)->obj_attrs_handle_unknown (err_bfd, tag);` => null pointer dereference -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29820] New: ld x86: -r should not define _TLS_MODULE_BASE_
https://sourceware.org/bugzilla/show_bug.cgi?id=29820 Bug ID: 29820 Summary: ld x86: -r should not define _TLS_MODULE_BASE_ Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- cat > a.s <: 401000: 48 c7 c0 e0 ff ff ff movq$-0x20, %rax # should be $0x0 401007: 66 90 nop 401009: 64 8b 90 e8 ff ff ff movl%fs:-0x18(%rax), %edx 401010: 64 03 90 ec ff ff ff addl%fs:-0x14(%rax), %edx 401017: 48 c7 c0 e0 ff ff ff movq$-0x20, %rax # should be $0x0 40101e: 66 90 nop 401020: 64 8b 90 f8 ff ff ff movl%fs:-0x8(%rax), %edx 401027: 64 03 90 fc ff ff ff addl%fs:-0x4(%rax), %edx -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Assignee|ccoutant at gmail dot com |i at maskray dot me Target Milestone|--- |2.40 Resolution|--- |FIXED --- Comment #3 from Fangrui Song --- Closed by https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=332a4eeaea69034b8ee6f50b931ce6734b55bf08 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8b2d02cbb924f1f3718dc5a20f7a9dcf07739d23 Milestone: 2.40 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 Fangrui Song changed: What|Removed |Added Assignee|unassigned at sourceware dot org |i at maskray dot me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Implemented in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f5a3546126b47fd3b7a5fbc4ec5fad1397b726b (readelf: support zstd compressed debug sections [PR 29640]) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #3 from Fangrui Song --- (In reply to Fangrui Song from comment #2) > https://sourceware.org/pipermail/binutils/2022-October/123240.html [PATCH] > readelf: support zstd compressed debug sections [PR 29640] The patch is stilling waiting for a review:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 --- Comment #2 from Fangrui Song --- (In reply to Nick Clifton from comment #1) > Created attachment 14403 [details] > Proposed patch > > Hi Fanguri, > > Is this patch the kind of thing that you had in mind ? > > Cheers > Nick Hi Nick, thanks for sending a patch! This looks good with just one thought: `config.fatal_warnings = false;` makes me wonder how -w interacts with --fatal-warnings. It seems that -w --fatal-warnings and --fatal-warnings -w have the same effect (-w wins, which makes sense IMO), so I guess `config.fatal_warnings = false;` can be omitted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] New: ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 Bug ID: 29654 Summary: ld: add -w to suppress warnings Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Apple ld64 and llvm-project ld64.lld support -w to suppress warnings. -w was picked likely because compiler drivers use -w to suppress warnings. I think -w mildly benefits GNU ld/gold as well. With --noinhibit-exec, we downgrade errors to warnings. When analyzing a large executable with relocation overflow issues, we may use --noinhibit-exec --emit-relocs to get relocations and an output file despite relocation overflow issues. Since we know the output otherwise does not link, the warnings are not useful. If we have -w, we can add -w to not see the unuseful warnings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #2 from Fangrui Song --- https://sourceware.org/pipermail/binutils/2022-October/123240.html [PATCH] readelf: support zstd compressed debug sections [PR 29640] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 --- Comment #2 from Fangrui Song --- bfd/compress.c is used by many utilities (objcopy/addr2line/objdump/etc), but gas/readelf need to implement their own. gold/dwp share code and need separate support as well. https://sourceware.org/pipermail/binutils/2022-October/123232.html [PATCH] gold, dwp: support zstd compressed input debug sections [PR 29641] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29641 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] New: gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Bug ID: 29641 Summary: gold, dwp: support zstd for SHF_COMPRESSED debug sections Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: i at maskray dot me CC: ian at airs dot com Target Milestone: --- dwp needs to decompress compressed .dwo . gold needs to decompress compressed input sections and compress output debug sections. I can take a stab on this feature request. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Fangrui Song changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29397 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #1 from Fangrui Song --- Also, the --decompress option decompresses section content. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 --- Comment #3 from Fangrui Song --- (In reply to Fangrui Song from comment #2) > https://sourceware.org/pipermail/gdb-patches/2022-September/191915.html > [PATCH] binutils, gdb: support zstd compressed debug sections The latest version is at https://sourceware.org/pipermail/binutils/2022-September/123085.html . The gdb part has been approved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 --- Comment #2 from Fangrui Song --- The spec (https://sourceware.org/gnu-gabi/program-loading-and-dynamic-linking.txt) doesn't reject it. For a section whose content is a concatenated N items, the ELF spirits typically allows N==0, as otherwise it needs an additional sentence to disallow the case, which is unnecessary. It seems that the reference implementation of Go may generate .gnu.version_r at least in some cases: https://github.com/llvm/llvm-project/issues/57707 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 --- Comment #2 from Fangrui Song --- https://sourceware.org/pipermail/gdb-patches/2022-September/191915.html [PATCH] binutils, gdb: support zstd compressed debug sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added Assignee|unassigned at sourceware dot org |i at maskray dot me -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/19109] Cannot configure default flag_compress_debug
https://sourceware.org/bugzilla/show_bug.cgi?id=19109 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #40 from Fangrui Song --- If binutils adds zstd (PR29397), the option --enable-compressed-debug-sections= needs to be adjusted:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] New: objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 Bug ID: 29566 Summary: objdump -p considers an empty .gnu.version_r invalid Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.yaml --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_EXEC Machine: EM_X86_64 Sections: - Name:.gnu.version_r Type:SHT_GNU_verneed Flags: [ SHF_ALLOC ] DynamicSymbols: - Name:f1 Binding: STB_GLOBAL % yaml2obj a.yaml -o a.o# a utility from llvm-project . On Debian, the package "llvm" contains it. % objdump -p a.o a.o: file format elf64-x86-64 objdump: a.o: .gnu.version_r invalid entry objdump: warning: private headers incomplete: bad value % readelf -V a.o Version needs section '.gnu.version_r' contains 0 entries: Addr: 0x Offset: 0x40 Link: 3 (.dynstr) --- objdump -p gives a warning while readelf -V doesn't. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections on .eh_frame => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 Fangrui Song changed: What|Removed |Added Summary|gold: --emit-relocs |gold: --emit-relocs |--gc-sections => internal |--gc-sections on .eh_frame |error in do_layout, at |=> internal error in |../../gold/object.cc|do_layout, at ||../../gold/object.cc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 --- Comment #3 from Fangrui Song --- See https://github.com/llvm/llvm-project/issues/57545 for a llvm-project/bolt --emit-relocs link issue due to this gold bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 Fangrui Song changed: What|Removed |Added CC||806251055 at qq dot com --- Comment #2 from Fangrui Song --- *** Bug 27741 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
