[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #2 from Andrew Oates --- Thanks! I have tested the linked patch and confirmed it fixes building with my original linker script and my testcase. One of the reasons I didn't realize the archive syntax was the right approach is that path matching behavior seems to be different between the undocumented form I've been using, and the proper archive form --- again, I don't totally understand the nuance, but in the testcase, if I move lib1.a into a subdirectory, "lib.a(*)" matches (pre 2.39, and with this patch), while "lib1.a:(*)" and "lib1.a:*(*)" _don't_ match (but "*/lib1.a:(*)" and variants do). That is surprising to me, but AFAICT is unrelated to this issue. -- 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.
Issue 57729 in oss-fuzz: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line
Updates: Labels: Deadline-Approaching Comment #2 on issue 57729 by sheriffbot: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57729#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gas/30585] as ignores {disp16} in 16bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30585 --- Comment #2 from Andi Kleen --- Thanks. So if it's already fixed that's fine. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30585] as ignores {disp16} in 16bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30585
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2023-06-27
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
CC||hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu ---
Works for me with 2.39:
[hjl@gnu-cfl-3 tmp]$ cat y.s
.code16
{disp16} jmp 1f
nop
1:
[hjl@gnu-cfl-3 tmp]$ gcc -c y.s
[hjl@gnu-cfl-3 tmp]$ objdump -dw -Mi8086 y.o
y.o: file format elf64-x86-64
Disassembly of section .text:
<.text>:
0: e9 01 00jmp0x4
3: 90 nop
[hjl@gnu-cfl-3 tmp]$
It is probably fixed by
commit 1a42a9fe4e60599bba1f047743a5b8b2ba96ee1f
Author: Jan Beulich
Date: Tue Apr 12 09:01:55 2022 +0200
x86: make {disp16} work similarly to {disp32}
In a few places {disp32} was handled specially when really {disp16}
wants handling just the same.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 Michael Matz changed: What|Removed |Added Assignee|unassigned at sourceware dot org |matz at suse dot de Last reconfirmed||2023-06-27 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #1 from Michael Matz --- The patch I posted at https://sourceware.org/pipermail/binutils/2023-June/128002.html should fix this (but please test on your full example). A note for the future: if you want to name archives in the file-part of section globs, then the documented forms are (and I'll cite): You can also specify files within archives by writing a pattern matching the archive, a colon, then the pattern matching the file, with no whitespace around the colon. 'archive:file' matches file within archive 'archive:' matches the whole archive ':file' matches file but not one in an archive Either one or both of 'archive' and 'file' can contain shell wildcards. That it worked formerly with just "lib1.a(*)" is an undocumented behaviour that got lost with my prefix-tree matching (and is reinstated with above patch). The above forms would have worked. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30591] New: [RISCV] Resolve pcrel relocations to local symbols when not relaxing
https://sourceware.org/bugzilla/show_bug.cgi?id=30591 Bug ID: 30591 Summary: [RISCV] Resolve pcrel relocations to local symbols when not relaxing Product: binutils Version: 2.41 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sch...@linux-m68k.org Target Milestone: --- Target: riscv*-*-* When the assembler is called with -mno-relax there is no reason to emit pc-relative relocations to local labels in the same section as their offset to the target address is known. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30568] --dependency-file includes temporary LTO files
https://sourceware.org/bugzilla/show_bug.cgi?id=30568 --- Comment #2 from Nikita Popov --- Thanks for the patch! > I have a couple of concerns with the patch. The first is that it uses a > simple heuristic to detect LTO generated filenames. I have no idea how > robust this will be. Yes, I agree. The checked sub-strings are pretty short, so it seems likely that there will be conflicts with real linker inputs. For example, LLVM has a tool called llvm-lto, so it seems pretty conceivable that "llvm-lto-" appears as part of a file name. It would be preferable if we could exclude all files added by the add_input_file hook from the dependency tracking. In the original report I suggested using the existing lto_output flag to distinguish this (for ld.bfd) -- is there any reason why that wouldn't work? (Another possibility would be to check whether the file still exists when writing the dependency file -- but I'm not sure whether these files have already been deleted at that point, or whether that happens later.) > The second is that the patch strips the filenames from the command line that > forms the first part of the dependency file, as well as the list of files > that comes afterwards. I ma not sure if this is the correct thing to do. > Maybe the command line should remain unfiltered. This is the right thing to do: The part at the start isn't a command line, but rather the actual dependency list in Makefile format, so we do want to filter that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30588] please make --disable-libsframe work
https://sourceware.org/bugzilla/show_bug.cgi?id=30588 --- Comment #4 from Andreas Schwab --- They should probably by moved to libiberty. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Bug in linker script file matching after b1eecf6f66a4a642 (prefix tree)
On Mon, Jun 26, 2023 at 8:40 AM Nick Clifton wrote:
>
> Hi Andrew,
>
> > Apologies for the generic subject, I don't totally understand the
> > nature of the bug.
>
> No worries. You have the problem narrowed down to a single commit,
> which definitely helps.
>
> > I have a basic linker script that stopped working after upgrading to
> > binutils 2.40. I did a git bisect on the repository and it seems that
> > the breakage starts with commit
> > b1eecf6f66a4a642f4cb35688213e6c1c1ffdc79.
>
> Please could you file a bug report for this problem here:
>
>https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
>
> Having a bug report like this really helps us to track the bug
> and ensure that it can be reviewed in the future, should it ever
> come back.
Done, thanks! https://sourceware.org/bugzilla/show_bug.cgi?id=30590
>
>
> > $ ${LD} -o out.bin -T linker.ld lib1.a lib2.a
>
> You have now shown how lib1.a and lib2.a are created. I assumed
> that you did:
>
>$ ar cr lib1.a test1.o test2.o
>$ ar cr lib2.a test3.o
Yes, forgot that part
>
>
> > $ objdump -x out.bin | grep func
> > c01e g F .text 000a func3
> > c00f g F .text 000f func1
> > c000 g F .text 000f func2
> >
> > you see that func1 and func2 are in .text rather than .init-text where
> > they should be.
>
> Yes, this is a bug. Not sure of the exact cause, but maybe the
> new code in commit b1eecf6f66a4a642 in scanning the sections in
> reverse order rather than forward order.
>
> Cheers
>Nick
>
>
[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.
