[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 binutils/31327] libbacktrace test failures
https://sourceware.org/bugzilla/show_bug.cgi?id=31327 Sam James changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #6 from Sam James --- commit b450e102730c527ec3b7164b119362a15ce545e6 (upstream/master) Author: Sam James Date: Mon Mar 11 17:21:07 2024 + Sync libbacktrace from gcc [PR31327] Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC. This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk. Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b which would've required an autoreconf, as it should be handled separately. Approved-By: Tom Tromey -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31474] New: Strip permission denied
https://sourceware.org/bugzilla/show_bug.cgi?id=31474 Bug ID: 31474 Summary: Strip permission denied Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pandom79 at gmail dot com Target Milestone: --- I have a weird problem with strip command. When I run "strip" command from a shell script, I get a permission denied error. Instead, if I run the same command from a terminal session, it works! Is it a bug or do i wrong anything? Regards -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31474] Strip permission denied
https://sourceware.org/bugzilla/show_bug.cgi?id=31474 Domenico Panella changed: What|Removed |Added CC||pandom79 at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31473] New: readelf --debug-dump=frames silently does nothing
https://sourceware.org/bugzilla/show_bug.cgi?id=31473 Bug ID: 31473 Summary: readelf --debug-dump=frames silently does nothing Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tromey at sourceware dot org Target Milestone: --- I have an executable that has a somewhat invalid/odd .eh_frames section. I found out that "readelf --debug-dump=frames" will just print the "intro" header and then nothing else, because this file causes frame_need_space to take one of the early "return -1" paths. I think it would be nice if these paths (there are 2) would print an error before returning. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31459] need a way to suppress the stderr message
https://sourceware.org/bugzilla/show_bug.cgi?id=31459 --- Comment #3 from Ruud van der Pas --- Great to hear this works for you, James! It is interesting that the outfile option on the collect command was never documented, but is clearly useful. The unfortunate thing is that the outfile option as supported on gp-display-text has a different behaviour: $ gprofng display text -outfile LOG -limit 5 -functions graph.2.thr.er Print limit set to 5 $ cat LOG Functions sorted by metric: Exclusive Total CPU Time Excl. TotalIncl. Total Name CPUCPU sec. %sec. % 15.905 100.00 15.905 100.00 6.464 40.64 6.467 40.66 verify_bfs_tree._omp_fn.0 4.700 29.55 4.716 29.65 make_bfs_tree._omp_fn.0 0.716 4.50 0.716 4.50 mrg_get_uint_orig 0.695 4.37 0.695 4.37 __aarch64_ldadd8_sync $ As you can see, outfile stores the output from the command, but not the diagnostics. This is why it might be cleaner and clearer to introduce a new option on the gp-collect-app command. Something like -gp-output. It would be the same as --outfile, but possibly avoid confusion. Your feedback is much appreciated! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31459] need a way to suppress the stderr message
https://sourceware.org/bugzilla/show_bug.cgi?id=31459 --- Comment #2 from James Carlson --- Excellent! I'll use that instead. In that case, please consider adding this option to the documentation. -- You are receiving this mail because: You are on the CC list for the bug.
