[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #10 from Harmen Stoppels --- Ah OK, I thought add_input_library() was immediate. Thanks for the patch! Sounds like this is easier to implement correctly and more convenient to use as a builtin feature. I could bring that up in a separate discussion. Even for trivial things like this message "got deps for library ...": that should probably be part of `ld --verbose` output only, but currently it can't be because plugins don't know about that flag. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31929] x86_64-w64-mingw32-ld: final link failed: bad value
https://sourceware.org/bugzilla/show_bug.cgi?id=31929
--- Comment #2 from Ralf Habacker ---
(In reply to Ralf Habacker from comment #1)
> It doesn't seem to be so easy to find the appropriate place. Is there a way
> to output the file and line where bfd_set_error() is called ?
It looks like there is no such option for end users. The only supported option
seems to be using a debugger and setting a breakpoint in the hope that you
don't reach the appropriate one at some point.
In the specific case this is:
#0 bfd_set_error (error_tag=error_tag@entry=bfd_error_bad_value) at
../../bfd/bfd.c:800
#1 0x5c942a in bfd_set_section_contents
(abfd=abfd@entry=0x7233b0, section=0x7253a8,
location=, offset=, count=)
at ../../bfd/section.c:1509
#2 0x555de5f0 in _bfd_coff_link_input_bfd
(flaginfo=flaginfo@entry=0x7fffe090,
input_bfd=input_bfd@entry=0x5b626720) at ../../bfd/cofflink.c:2509
#3 0x5df937 in _bfd_coff_final_link (abfd=,
info=0x700de0 ) at ../../bfd/cofflink.c:898
#4 0x59af8e in ldwrite () at ../../ld/ldwrite.c:550
#5 0x55582bfe in main (argc=, argv=) at
../../ld/ldmain.c:528
The generated file has the following size at this point
-rw-r--r-- 1 abuild abuild 3087021376 Jun 26 14:22 Qt5WebKit.dll
and the error is triggered in the following function:
1490 bfd_set_section_contents (bfd *abfd,
1491 sec_ptr section,
1492 const void *location,
1493 file_ptr offset,1494 bfd_size_type count)1495 {1496 bfd_size_type
sz;14971498 if (!(bfd_section_flags (section) & SEC_HAS_CONTENTS))1499 {
1500 bfd_set_error (bfd_error_no_contents);
1501 return false;
1502 }
1503
1504 sz = section->size;
1505 if ((bfd_size_type) offset > sz
1506 count > sz - offset
1507 count != (size_t) count)
1508 {
1509 bfd_set_error (bfd_error_bad_value);
1510 return false;
1511 }
After inspecting the individual values:
(gdb) p o->output_offset
$17 = 2762844077
(gdb) p loc
$18 =
(gdb) p o->size
$19 = 4898386
and interpretation is obtained:
offset 2762844077
sz 2764867072 section_size
count 4898386
sz-offset 2022995
The checked conditions
1505: Offset > sz --> no
1506: Count > sz - offset -> yes
show that the comparison in line 1506 leads to the error.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31924] aarch64 kernels built with binutils 2.42.50.20240618 and later fail to boot
https://sourceware.org/bugzilla/show_bug.cgi?id=31924 --- Comment #9 from Szabolcs Nagy --- it seems arm64 linux passes --no-apply-dynamic-relocs which means the relative reloc addend is not stored to the referenced location (0 is stored) and since -z pack-relative-relocs does not have the addend stored elsewhere, the linux self-relocation code can't work. so either linux is wrong for passing --no-apply-dynamic-relocs -z pack-relative-relocs together or ld should ignore --no-apply-dynamic-relocs in this case. i think linux is wrong here. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Makefile#n15 if i edit that out then i get a bootable Image. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31924] aarch64 kernels built with binutils 2.42.50.20240618 and later fail to boot
https://sourceware.org/bugzilla/show_bug.cgi?id=31924 --- Comment #10 from Tj --- On Friday, 28 June 2024 at 13:52, nsz at gcc dot gnu.org wrote: > > so either linux is wrong for passing > > --no-apply-dynamic-relocs -z pack-relative-relocs > > together or ld should ignore --no-apply-dynamic-relocs in this case. > i think linux is wrong here. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Makefile#n15 > > if i edit that out then i get a bootable Image. > Did you notice my finding about zboot.lds and removing the DISCARD ? That was only added in v6.9 with commit 5134acb15d9ef27aa2b90aad46d and is targeted at loongarch so I suspect that commit needs reverting and redoing to be conditional on the architecture. > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31924] aarch64 kernels built with binutils 2.42.50.20240618 and later fail to boot
https://sourceware.org/bugzilla/show_bug.cgi?id=31924 Ard Biesheuvel changed: What|Removed |Added CC||ardb at kernel dot org --- Comment #11 from Ard Biesheuvel --- (In reply to Tj from comment #10) > On Friday, 28 June 2024 at 13:52, nsz at gcc dot gnu.org > wrote: > > > > > so either linux is wrong for passing > > > > --no-apply-dynamic-relocs -z pack-relative-relocs > > > > together or ld should ignore --no-apply-dynamic-relocs in this case. > > i think linux is wrong here. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Makefile#n15 > > > > if i edit that out then i get a bootable Image. > > > > Did you notice my finding about zboot.lds and removing the DISCARD ? > > That was only added in v6.9 with commit 5134acb15d9ef27aa2b90aad46d and is > targeted at loongarch so I suspect that commit needs reverting and redoing > to be conditional on the architecture. That seems spurious to me - zboot.lds is not used for building Image, only for building vmlinuz.efi, which incorporates a compressed copy of Image. (In reply to Szabolcs Nagy from comment #9) > it seems arm64 linux passes --no-apply-dynamic-relocs which means > the relative reloc addend is not stored to the referenced location > (0 is stored) and since -z pack-relative-relocs does not have the > addend stored elsewhere, the linux self-relocation code can't work. > > so either linux is wrong for passing > >--no-apply-dynamic-relocs -z pack-relative-relocs > > together or ld should ignore --no-apply-dynamic-relocs in this case. > i think linux is wrong here. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/ > arm64/Makefile#n15 > > if i edit that out then i get a bootable Image. Agree that this combination makes no sense, although LLD does the right thing here. So the Makefile logic should be updated to only pass --no-apply-dynamic-relocs if CONFIG_RELR is not set. That would result in all locations to have the addend stored, even the ones that are covered by RELA rather than RELR (assuming ld.bfd could emit both just like LLD) but that shouldn't matter - RELR saves so much space that the overhead of a handful of less compressible statically initialized pointers should be negligible. -- You are receiving this mail because: You are on the CC list for the bug.
