[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-23 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Nick Clifton --- Hi Jason, Thanks for the test case. There was a small problem with it, in that it deletes all of the temporary files at the end, including the newly built wireguard.ko, which makes it hard to investigate. Anyway I was able to capture the wireguard.ko file and I checked - the R_ARM_THM_JUMP11 reloc is certainly there, but it is also valid. The relocation can be processed to produce a valid branch instruction. > The kernel module loader then sees R_ARM_THM_JUMP11 and refuses to load it, > because it doesn't do JUMP11 relocations. This sounds to me like a kernel bug. Why does it not support the R_ARM_THM_JUMP11 relocation ? It supports other relocations, right ? I am inclined to consider this as not being a bug. Given that you have a workaround, and, to my mind, the real culprit is the kernel. Nevertheless I can appreciate that fixing the kernel might be difficult, so I can see the appeal of an assembler based solution. As it happens the assembler already has some special case code to cover other relocations not supported by the kernel, so adding one more should not hurt. Thus I am uploading a patch for you to test. Please could you try it out and let me know if it works ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 --- Comment #5 from Nick Clifton --- Created attachment 12652 --> https://sourceware.org/bugzilla/attachment.cgi?id=12652&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Kees, Are you able to supply a small test case that demonstrates the problem ? Preferably something that does not involve building an entire kernel... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 --- Comment #6 from Jason A. Donenfeld --- (In reply to Nick Clifton from comment #4) > Hi Jason, > > Thanks for the test case. There was a small problem with it, in that > it deletes all of the temporary files at the end, including the newly > built wireguard.ko, which makes it hard to investigate. Whoops. Was my expectation that you'd want to modify that, of course. :) > > Anyway I was able to capture the wireguard.ko file and I checked - > the R_ARM_THM_JUMP11 reloc is certainly there, but it is also valid. > The relocation can be processed to produce a valid branch instruction. > > > > The kernel module loader then sees R_ARM_THM_JUMP11 and refuses to load it, > > because it doesn't do JUMP11 relocations. > > This sounds to me like a kernel bug. Why does it not support the > R_ARM_THM_JUMP11 relocation ? It supports other relocations, right ? It's not a kernel bug. See the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Kconfig?id=5e857ce6eae7ca21b2055cca4885545e29228fe2#n1431 } Various binutils versions can resolve Thumb-2 branches to } locally-defined, preemptible global symbols as short-range "b.n" } branch instructions. } } This is a problem, because there's no guarantee the final } destination of the symbol, or any candidate locations for a } trampoline, are within range of the branch. For this reason, the } kernel does not support fixing up the R_ARM_THM_JUMP11 (102) } relocation in modules at all, and it makes little sense to add } support. } } The symptom is that the kernel fails with an "unsupported } relocation" error when loading some modules. The commit goes onto describe a workaround, which is no longer necessary, as binutils has been fixed. At least until this new bug: } Until fixed tools are available, passing } -fno-optimize-sibling-calls to gcc should prevent gcc generating } code which hits this problem, at the cost of a bit of extra runtime } stack usage in some cases. } } The problem is described in more detail at: } https://bugs.launchpad.net/binutils-linaro/+bug/725126 } } Only Thumb-2 kernels are affected. } } Unless you are sure your tools don't have this problem, say Y. It's now possible to say N there, except if you use -fvisibility=hidden, which is what I ran into. > I am inclined to consider this as not being a bug. Given that you > have a workaround, and, to my mind, the real culprit is the kernel. > Nevertheless I can appreciate that fixing the kernel might be > difficult, so I can see the appeal of an assembler based solution. I don't know how to decide whose bug this is, but at least the last time it came up, it was considered a binutils deficiency that got fixed, so I would assume similar reason applies to this bug too. > As it happens the assembler already has some special case code to > cover other relocations not supported by the kernel, so adding one > more should not hurt. Thus I am uploading a patch for you to test. > Please could you try it out and let me know if it works ? Oh, great, thanks a lot. I'll give it a try and will let you know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #10 from Alan Modra --- This took a little time to recreate, mainly due to using $(wildcard ) in the makefile. That was a bad idea, because the order of files in the archive matters for this testcase, and apparently my file order was different to yours. Anyway, the trigger for the ld problem here is that you used plain "ar" to create the archive rather than "gcc-ar" or "ar --plugin ...liblto_plugin.so". That leads to the archive map using the normal object file symbols rather than the lto symbols, and there is a difference in the case of that quite nasty archive0__object1.o generated from assembly. $ aarch64-linux-nm archive0__object1.o U archive0__object0 T archive0__object1 $ aarch64-linux-gcc-nm archive0__object1.o /usr/local/bin/../lib/gcc/aarch64-linux/11.0.0/../../../../aarch64-linux/bin/nm: archive0__object1.o: no symbols $ aarch64-linux-nm --plugin /usr/local/libexec/gcc/aarch64-linux/11.0.0/liblto_plugin.so archive0__object1.o aarch64-linux-nm: archive0__object1.o: no symbols So the lesson for users is to not write asm statements that define global symbols, particularly if the C file might be compiled with -flto. Catching this case in the linker is a pain. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 Alan Modra changed: What|Removed |Added Summary|Assertion failure at|Assertion failure at |ldlang.c:7269 when using|ldlang.c:7269 when using |inline assembly, -flto and |inline assembly, -flto and |--no-whole-archive |--start-group Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2020-06-23 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #11 from Pekka Seppänen --- Oh my... I completely forgot the --plugin part and how it participates with ar. This is my bad, sorry :( Indeed the resulting (thin) archive is a bit different whether or not --plugin is there, namely how archive0__object1 is mapped in this case. So, in a sense that assertation is simply a red herring. There could be yet another way of triggering this same problem, again, due to not properly using --plugin when creating an archive with object files compiled using -flto and inline assembly. I originally stubled upon this as I have a few locations that require naked functions when forwarding calls between different rings. For AArch64 GCC does unfortunately support those, so I simply had a similar inline shims; Those do not actually reference any symbols but are referenced within the same library. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Alan Modra --- The kernel folk are generating PIEs and then being surprised about linker generated dynamic sections. In this particular case the .gnu.version* happen to end up as zero sized and are removed from the final output. That doesn't mean that --orphan-handling=warn or error should be silent. A zero size orphan is still an orphan, and in the case of dynamic sections their size isn't known at the time sections are mapped to output. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26160] New: [2.35 Regression] Warning: index table size is too small 0 vs 70
https://sourceware.org/bugzilla/show_bug.cgi?id=26160 Bug ID: 26160 Summary: [2.35 Regression] Warning: index table size is too small 0 vs 70 Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: nickc at redhat dot com Blocks: 26112 Target Milestone: --- commit e4b7104b1e0c70613d0f553cb18d25c7343647d3 Author: Nick Clifton Date: Mon Jun 22 17:44:56 2020 +0100 Add support for decoding the DW_MACRO_define_strx and DW_MACRO_undef_strx operands found in DWARF-5 .debug_macro sections. caused: FAIL: dwp_test_2.sh FAIL: dwp_test_1.sh in gold test: $ ../../binutils/readelf -wi dwp_test_1.dwp > dwp_test_1.stdout readelf: Warning: index table size is too small 0 vs 70 ... Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=26112 [Bug 26112] readelf --debug-dump=macro can't parse clang debug info -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 H.J. Lu changed: What|Removed |Added Depends on||26160 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=26160 [Bug 26160] [2.35 Regression] Warning: index table size is too small 0 vs 70 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26160] [2.35 Regression] Warning: index table size is too small 0 vs 70
https://sourceware.org/bugzilla/show_bug.cgi?id=26160 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi H.J. Sorry about that - this is due to my patch to add support for the DW_MACRO_define_strx operand, which is not handling .debug_str_offsets.dwo sections correctly. I have a local patch which I am testing at this moment. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=80fda85ca18ee287c826a90b09c5cb8e20fd4d54 commit 80fda85ca18ee287c826a90b09c5cb8e20fd4d54 Author: H.J. Lu Date: Tue Jun 23 06:50:23 2020 -0700 Add a testcase for PR binutils/26112 PR binutils/26112 * testsuite/binutils-all/pr26112.o.bz2: New file. * testsuite/binutils-all/pr26112.r: Likewise. * testsuite/binutils-all/readelf.exp: Run PR binutils/26112 test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26160] [2.35 Regression] Warning: index table size is too small 0 vs 70
https://sourceware.org/bugzilla/show_bug.cgi?id=26160 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Right - this should now be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26160] [2.35 Regression] Warning: index table size is too small 0 vs 70
https://sourceware.org/bugzilla/show_bug.cgi?id=26160 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39f381cb80463bd814da549a927bee4643d4ceac commit 39f381cb80463bd814da549a927bee4643d4ceac Author: Nick Clifton Date: Tue Jun 23 16:06:38 2020 +0100 Fix decoding of indexed DWARF strings using pre-DWARF-5 string offset sections. Fix display of .debug_str_offsets.dwo sections. PR 26160 * dwarf.c (fetch_indexed_string): Detect and handle old style .debug_str_offset tables. (display_debug_str_offsets): Likewise. Also add support for .debug_str_offsets.dwo sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 Bug 26112 depends on bug 26160, which changed state. Bug 26160 Summary: [2.35 Regression] Warning: index table size is too small 0 vs 70 https://sourceware.org/bugzilla/show_bug.cgi?id=26160 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9221725d1f6e3f5dd0c0143ee750460619c582f2 commit 9221725d1f6e3f5dd0c0143ee750460619c582f2 Author: Alan Modra Date: Tue Jun 23 23:50:56 2020 +0930 PR26150, Assertion when asm() defines global symbols, -flto and --start-group If an archive map contains symbols that aren't actually defined by the indexed element for any reason, then loading that element will leave the symbol undefined (or common). This leads to the possibility of the element being loaded again should the archive be searched again due to the action of --start-group/--end-group. The testcase triggering this problem was an archive containing fat lto objects, with the archive map incorrectly created by ar rather than gcc-ar. PR 26150 * ldlang.c (ldlang_add_file): Assert that we aren't adding the current end of link.next list again too. * ldmain.c (add_archive_element): Don't load archive elements again that have already been loaded. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26160] [2.35 Regression] Warning: index table size is too small 0 vs 70
https://sourceware.org/bugzilla/show_bug.cgi?id=26160 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d0dded5bc251e506ef65b13696c624ea8669ed6e commit d0dded5bc251e506ef65b13696c624ea8669ed6e Author: H.J. Lu Date: Tue Jun 23 09:19:05 2020 -0700 Add a testcase for PR binutils/26160 PR binutils/26160 * testsuite/binutils-all/pr26160.dwp.bz2: New file. * testsuite/binutils-all/pr26160.r: Likewise. * testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #3 from Fangrui Song ---
Does this suggest that GNU ld --orphan-handling should ignore unused linker
created sections? (FWIW I did this for LLD in https://reviews.llvm.org/D75149 )
If no symbol versioning feature is used, the output naturally has no
.gnu.version{,_r,_d} - this is a guaranteed property of ld. Therefore, I think
the user does not have to specify an empty .gnu.version{,_r,_d} output section
description just to suppress the --orphan-handling={warn,error} diagnostic.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/22843] Provide dependency information from the linker similar to the compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=22843 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Roland McGrath : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f37b21b481a7804a13c5806098c19b6119288ba4 commit f37b21b481a7804a13c5806098c19b6119288ba4 Author: Roland McGrath Date: Tue Jun 23 12:01:24 2020 -0700 PR 22843: ld, gold: Add --dependency-file option. gold/ * options.h (class General_options): Add --dependency-file option. * fileread.cc (File_read::files_read): New static variable. (File_read::open): Add the file to the files_read list. (File_read::record_file_read): New static member function. (File_read::write_dependency_file): New static member function. * fileread.h (class File_read): Declare them. * layout.cc (Layout::read_layout_from_file): Call record_file_read. (Close_task_runner::run): Call write_dependency_file if --dependency-file was passed. ld/ * NEWS: Note --dependency-file. * ld.texi (Options): Document --dependency-file. * ldlex.h (enum option_values): Add OPTION_DEPENDENCY_FILE. * ld.h (ld_config_type): New member dependency_file. * lexsup.c (ld_options, parse_args): Parse --dependency-file. * ldmain.c (struct dependency_file): New type. (dependency_files, dependency_files_tail): New static variables. (track_dependency_files): New function. (write_dependency_file): New function. (main): Call it when --dependency-file was passed. * ldfile.c (ldfile_try_open_bfd): Call track_dependency_files. (ldfile_open_command_file_1): Likewise. * ldelf.c (ldelf_try_needed): Likewise. * pe-dll.c (pe_implied_import_dll): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26163] New: Combination of LTO and -Wl,--defsym causes symbol to be resolved as NULL
https://sourceware.org/bugzilla/show_bug.cgi?id=26163
Bug ID: 26163
Summary: Combination of LTO and -Wl,--defsym causes symbol to
be resolved as NULL
Product: binutils
Version: 2.34
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: cbaylis at gcc dot gnu.org
Target Milestone: ---
Originally reported to GCC bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95846
The following program demonstrates this problem:
==< test1.c >==
#include
void f(void);
void g(void);
void f(void)
{
printf("in f()\n");
g();
printf("back in f()\n");
}
==< test2.c >==
#include
void f(void);
void real_g(void)
{
printf("in real_g()\n");
}
int main()
{
real_g();
f();
}
== end ==
$ gcc -Os -c test1.c
$ gcc -O2 -flto -c test2.c
$ gcc -O2 test1.o test2.o -o test -Wl,--defsym,g=real_g
$ ./test
in real_g()
in f()
Segmentation fault (core dumped)
The segfault is caused because there is no real_g symbol and g has been
resolved to NULL.
00401146 :
401146: 50 push %rax
401147: bf 15 20 40 00 mov$0x402015,%edi
40114c: e8 df fe ff ff callq 401030
401151: e8 aa ee bf ff callq 0 < oops!
401156: bf 10 20 40 00 mov$0x402010,%edi
40115b: 5a pop%rdx
40115c: e9 cf fe ff ff jmpq 401030
401161: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
401168: 00 00 00
40116b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
Seen on Fedora 32 (gcc 10.1.1, binutils 2.34) and Ubuntu 18.04 (gcc 7.5.0,
binutils 2.30)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26163] Combination of LTO and -Wl,--defsym causes symbol to be resolved as NULL
https://sourceware.org/bugzilla/show_bug.cgi?id=26163 H.J. Lu changed: What|Removed |Added URL||https://sourceware.org/pipe ||rmail/binutils/2020-June/11 ||1841.html Target Milestone|--- |2.35 --- Comment #1 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-June/111841.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22843] Provide dependency information from the linker similar to the compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=22843 Roland McGrath changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Roland McGrath --- Implemented --dependency-file in both gold and ld.bfd on trunk. -- You are receiving this mail because: You are on the CC list for the bug.
