[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 --- Comment #9 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=9810db10f726f47c8e878ca4b0b4b4f5e9c16a5d commit 9810db10f726f47c8e878ca4b0b4b4f5e9c16a5d Author: Alan Modra Date: Sat Feb 5 15:36:58 2022 +1030 PR28827 testcase This testcase triggers a stub sizing error with the patches applied for PR28743 (commit 2f83249c13d8 and c804c6f98d34). PR 28827 * testsuite/ld-powerpc/pr28827-1.s, * testsuite/ld-powerpc/pr28827-1.d: New test. * testsuite/ld-powerpc/powerpc.exp: Run it. -- You are receiving this mail because: You are on the CC list for the bug.
Is this a bug?
Hi. I am trying to compile binutils 2.37. But when the Makefile runs gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.37/bfd "-DBINDIR=\\C:/test/normalGcc/bin\" -DLIBDIR=\"C:/test/normalGcc/lib\" -I. -I../../binutils-2.37/bfd -I../../binutils-2.37/bfd/../include -DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_i386_coff_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I../../binutils-2.37/bfd/../zlib -g -O2 -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c -o archive.lo ../../binutils-2.37/bfd/archive.c" -o archive.o I get an error gcc.exe: fatal error: no input files What do I do?
[Bug gas/28863] two-argument .align is accepted for RISC-V but the alignment is not always preserved
https://sourceware.org/bugzilla/show_bug.cgi?id=28863 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Target||riscv -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28863] New: two-argument .align is accepted for RISC-V but the alignment is not always preserved
https://sourceware.org/bugzilla/show_bug.cgi?id=28863 Bug ID: 28863 Summary: two-argument .align is accepted for RISC-V but the alignment is not always preserved Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Created attachment 13958 --> https://sourceware.org/bugzilla/attachment.cgi?id=13958=edit align2.s Building the attached program with the following commands results in misalignment of the 'bar' label in the final executable: riscv32-unknown-elf-as align2.s -o align2.o riscv32-unknown-elf-ld align2.o -o align2 riscv32-unknown-elf-objdump -dr align2 align2: file format elf32-littleriscv Disassembly of section .text: 00010060 <_start>: 10060: 0013nop 10064: 0013nop 10068: 0013nop 1006c: 0013nop 00010070 : 10070: 0013nop ... 0001007c : 1007c: 0013nop ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 --- Comment #8 from Alan Modra --- The major reason for layout to change is editing of .eh_frame and sizing of .eh_frame_hdr. Obviously we want to continue doing that, but what should *not* happen is changes in .got/.plt relative layout. Prior to HJ's two lang_size_relro_segment patches that didn't happen. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28862] New: heap-buffer-overflow in parse_stab_string
https://sourceware.org/bugzilla/show_bug.cgi?id=28862 Bug ID: 28862 Summary: heap-buffer-overflow in parse_stab_string Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: wyxaidai at gmail dot com Target Milestone: --- Created attachment 13956 --> https://sourceware.org/bugzilla/attachment.cgi?id=13956=edit poc ~/fuzzing/binutils/binutils-gdb/binutils/objdump -g poc poc: file format elf64-x86-64 /home/aidai/fuzzing/binutils/binutils-gdb/binutils/objdump: poc: invalid string offset 3774873600 >= 6 for section `.strtab' = ==3453842==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300150 at pc 0x5565159b86b3 bp 0x7ffe0db99410 sp 0x7ffe0db99400 READ of size 1 at 0x60300150 thread T0 #0 0x5565159b86b2 in parse_stab_string /home/aidai/fuzzing/binutils/binutils-gdb/binutils/stabs.c:1132 #1 0x5565159b6a24 in parse_stab /home/aidai/fuzzing/binutils/binutils-gdb/binutils/stabs.c:670 #2 0x5565159a5214 in read_section_stabs_debugging_info /home/aidai/fuzzing/binutils/binutils-gdb/binutils/rddbg.c:243 #3 0x5565159a44de in read_debugging_info /home/aidai/fuzzing/binutils/binutils-gdb/binutils/rddbg.c:56 #4 0x556515946d45 in dump_bfd objdump.c:5169 #5 0x556515946fec in display_object_bfd objdump.c:5225 #6 0x55651594737b in display_any_bfd objdump.c:5315 #7 0x5565159473f5 in display_file objdump.c:5336 #8 0x556515948ab7 in main objdump.c:5708 #9 0x7fe3b8eab0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #10 0x55651592e39d in _start (/home/aidai/fuzzing/binutils/binutils-gdb/binutils/objdump+0x13539d) 0x60300150 is located 0 bytes to the right of 32-byte region [0x60300130,0x60300150) allocated by thread T0 here: #0 0x7fe3b9189bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x556515d10543 in xmalloc xmalloc.c:149 #2 0x5565159a49ad in read_section_stabs_debugging_info /home/aidai/fuzzing/binutils/binutils-gdb/binutils/rddbg.c:140 #3 0x5565159a44de in read_debugging_info /home/aidai/fuzzing/binutils/binutils-gdb/binutils/rddbg.c:56 #4 0x556515946d45 in dump_bfd objdump.c:5169 #5 0x556515946fec in display_object_bfd objdump.c:5225 #6 0x55651594737b in display_any_bfd objdump.c:5315 #7 0x5565159473f5 in display_file objdump.c:5336 #8 0x556515948ab7 in main objdump.c:5708 #9 0x7fe3b8eab0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/aidai/fuzzing/binutils/binutils-gdb/binutils/stabs.c:1132 in parse_stab_string Shadow bytes around the buggy address: 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff8000: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8010: 00 fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa =>0x0c067fff8020: 00 00 00 fa fa fa 00 00 00 00[fa]fa 00 00 02 fa 0x0c067fff8030: fa fa 00 00 02 fa fa fa 00 00 00 fa fa fa 00 00 0x0c067fff8040: 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==3453842==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com CC|amodra at gmail dot com| --- Comment #7 from Alan Modra --- Matthias, thanks for making the object files available. That let me reproduce the failure, and it isn't anthing to do with what I thought might be going on at past 20 stub sizing iterations. The patches already applied for this bug on mainline don't fix the problem. We're getting a section layout quite different when sizing stubs to that when building stubs. In particular the gap at the of the relro segment changes, .plt is separated from .got. That means the offsets from the toc pointer reg to access addresses in the plt change. When the offsets change, the size of the required code to load those addresses can change. That's why the assertion triggers. A plt call stub increases in size, which then results in the next stub overwriting the end of the plt call stub. Reverting HJ's relro patches avoids the bug. -- You are receiving this mail because: You are on the CC list for the bug.
