[Bug binutils/30793] kvx_reassemble_bundle index 8 out of bounds
https://sourceware.org/bugzilla/show_bug.cgi?id=30793 Alan Modra changed: What|Removed |Added Target||kvx-linux-gnu CC||piannetta at kalrayinc dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30793] New: kvx_reassemble_bundle index 8 out of bounds
https://sourceware.org/bugzilla/show_bug.cgi?id=30793 Bug ID: 30793 Summary: kvx_reassemble_bundle index 8 out of bounds Product: binutils Version: 2.42 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- Created attachment 15083 --> https://sourceware.org/bugzilla/attachment.cgi?id=15083=edit test_file With fuzzed input it is possible to hit kvx-dis.c:479 with i = 8 if (kvx_has_parallel_bit (bundle_words[i])) Seen with objdump -D -m kvx:kv4-1 -b binary test_file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30781] Ranges section dump is broken if both ranges and rnglists sections are present
https://sourceware.org/bugzilla/show_bug.cgi?id=30781 --- Comment #5 from Vsevolod Alekseyev --- Found a similar but distinct bug on a v5 only binary, https://sourceware.org/bugzilla/show_bug.cgi?id=30792 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] New: Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 Bug ID: 30792 Summary: Rnglists section dump in readelf outputs one rangelist per CU Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 15082 --> https://sourceware.org/bugzilla/attachment.cgi?id=15082=edit dwarf_v5ops.so.zip Followup from #30781. Run the following with the attached binary: readelf --debug-dump=Ranges dwarf_v5ops.so.elf For the first CU in the rnglists section it outputs the range list at 0xc and moves on to the next CU. Meanwhile, there is a lot of perfectly valid rangelists remaining in the first CU. To name one, the rangelist at 0x1c is referenced by the DIE at 0x6afb (DW_TAG_inlined_subroutine inside of DW_TAG_subroutine for JiPad_AddPoint). The next rnglists-CU at 0x142 also lists only one rangelist. So does 0x10329, 0x103f1, and 0x105e9. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30791] New: Do not merge sections with same name and SHF_LINK_ORDER, but different sh_link value
https://sourceware.org/bugzilla/show_bug.cgi?id=30791
Bug ID: 30791
Summary: Do not merge sections with same name and
SHF_LINK_ORDER, but different sh_link value
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: zimao at microsoft dot com
Target Milestone: ---
When a section has both SHF_LINK_ORDER and sh_link set, it means this section
is kind of a child section of the linked to section.
When merging two sections with the same name, both have SHF_LINK_ORDER set, but
different sh_link value, one of the sh_link information will be absent in the
merged section.
In a real world example, both GCC (13.1) and clang (14.0) utilize this behavior
for the "-ffunction-sections -fpatchable-function-entry=N". The compiler will
generate multiple sections all named as "__patchable_function_entries", with
different sh_link. Each section will be linked its own .text section.
But when running code like `ld -r -o merged.o a.o b.o`, the current ld will
merge all these "__patchable_function_entries" section into a single section.
On the other hand, on the LLVM side, lld will keep these "pfe" sections
separately after the linking.
ref link: https://reviews.llvm.org/D68094
I think ld should not merge these sections as well, just like the behavior in
lld.
Example code:
$ cat a.c
int a(){return 1;}
int b(){return 2;}
$ cat b.c
int c(){return 3;}
int d(){return 4;}
$ gcc -c -ffunction-sections -fpatchable-function-entry=2 a.c b.c
$ readelf -S a.o
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 3] .text.a PROGBITS 0040
000d AX 0 0 16
[ 4] __patchable_[...] PROGBITS 0050
0008 WAL 3 0 8
[ 5] .rela__patch[...] RELA 0188
0018 0018 I 14 4 8
[ 6] .text.b PROGBITS 0060
000d AX 0 0 16
[ 7] __patchable_[...] PROGBITS 0070
0008 WAL 6 0 8
[ 8] .rela__patch[...] RELA 01a0
0018 0018 I 14 7 8
(some content removed, same result for the b.o)
$ ld -r -o merged.o a.o b.o
readelf -S merged.o | grep -E "(text)|(patchable)" -A1
[ 1] .text PROGBITS 0040
AX 0 0 4
[ 2] .text.a PROGBITS 0040
000d AX 0 0 16
[ 3] .text.b PROGBITS 0050
000d AX 0 0 16
[ 4] .text.c PROGBITS 0060
000d AX 0 0 16
[ 5] .text.d PROGBITS 0070
000d AX 0 0 16
--
[ 8] __patchable_[...] PROGBITS 0130
0020 WAL 2 0 8
$ ld.lld -r -o merged-2.o a.o b.o
$ readelf -S merged-2.o | grep -E "(text)|(patchable)" -A1
[ 1] .text PROGBITS 0040
AX 0 0 4
[ 2] .text.a PROGBITS 0040
000d AX 0 0 16
[ 3] __patchable_[...] PROGBITS 0050
0008 WAL 2 0 8
--
[ 5] .text.b PROGBITS 0060
000d AX 0 0 16
[ 6] __patchable_[...] PROGBITS 0070
0008 WAL 5 0 8
--
[12] .text.c PROGBITS 0130
000d AX 0 0 16
[13] __patchable_[...] PROGBITS 0140
0008 WAL 12 0 8
--
[15] .text.d PROGBITS 0150
000d AX 0 0 16
[16] __patchable_[...] PROGBITS 0160
0008 WAL 15 0 8
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 61011 in oss-fuzz: binutils:fuzz_dlltool: Heap-buffer-overflow in xstrdup
Updates: Labels: -restrict-view-commit Comment #3 on issue 61011 by sheriffbot: binutils:fuzz_dlltool: Heap-buffer-overflow in xstrdup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61011#c3 This bug has been fixed. It has been opened to the public. - 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.
Issue 59511 in oss-fuzz: binutils:fuzz_as: Heap-use-after-free in hash_symbol_entry
Updates: Labels: Deadline-Approaching Comment #2 on issue 59511 by sheriffbot: binutils:fuzz_as: Heap-use-after-free in hash_symbol_entry https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=59511#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 ld/30787] DT_JMPREL/DT_PLTRELSZ incorrect when PLT and REL/RELA relocations share an ELF output section
https://sourceware.org/bugzilla/show_bug.cgi?id=30787 --- Comment #4 from Peter Edwards --- Thanks for the fast turn-around! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30787] DT_JMPREL/DT_PLTRELSZ incorrect when PLT and REL/RELA relocations share an ELF output section
https://sourceware.org/bugzilla/show_bug.cgi?id=30787 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |2.42 Status|UNCONFIRMED |RESOLVED --- Comment #3 from H.J. Lu --- Fixed for 2.42. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30787] DT_JMPREL/DT_PLTRELSZ incorrect when PLT and REL/RELA relocations share an ELF output section
https://sourceware.org/bugzilla/show_bug.cgi?id=30787 --- Comment #2 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=fa4f2d46f95a1c673b025fab7f292cb864a99020 commit fa4f2d46f95a1c673b025fab7f292cb864a99020 Author: Peter Edwards Date: Tue Aug 22 19:57:28 2023 +0100 x86: Fix DT_JMPREL/DT_PLTRELSZ when relocs share a section If a linker script does not place the PLT relocations and "normal" relocations in separate ELF sections, `ld` will currently output incorrect values for DT_JMPREL and DT_PLTRELSZ - they cover the entire ELF section, rather than just the PLT relocations Don't ignore the extent of the BFD section - use the size of the srelplt BFD section and its offset from the output_secttion bfd/ PR ld/30787 * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use input section for DT_JMPREL and DT_PLTRELSZ. ld/ PR ld/30787 * testsuite/ld-i386/i386.exp: Run pr30787. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/pr30787.d: New file. * testsuite/ld-i386/pr30787.s: Likewise. * testsuite/ld-i386/pr30787.t: Likewise. * testsuite/ld-x86-64/pr30787.d: Likewise. * testsuite/ld-x86-64/pr30787.s: Likewise. * testsuite/ld-x86-64/pr30787.t: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30781] Ranges section dump is broken if both ranges and rnglists sections are present
https://sourceware.org/bugzilla/show_bug.cgi?id=30781 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nick Clifton --- OK, I have applied the patch (although I used the wrong PR number in the ChangeLog entry - sorry), so I am going to close this PR for now. If a case where mixed versions of the loclist sections turns up then we can reopen the PR. -- You are receiving this mail because: You are on the CC list for the bug.
