Re: Possible bug in objdump
Hi Joe, > The possible bug is explained in the comments near the beginning of the file > Bug.c Please could file a bug report using the binutils Bugzilla system here: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils When you do, it would be really helpful if you could include a copy of the "Bug" executable, as well as the other files, as it is very hard to ensure that we have exactly the same compilation environment as you have. As to the the bug itself: // 99f: 48 8b 05 8a 52 20 00movrax,QWORD PTR [rip+0x20528a] # 205c30 // // The instructions access XtStrings+0x48f0. However, if you look at Bug.elf you see // // 11: 00201340 2649 OBJECT GLOBAL DEFAULT 21 XtStrings // // The size of XtStrings is 2649 decimal. But XtStrings+0x48f0 is beyond the region occupied by XtStrings. My guess is that the disassembler has chosen XtStrings as being the nearest user-visible symbol to the address referenced, in the hopes that it might be useful to the reader. The disassembler is not saying that the XtStrings array is actually being used, but merely that it could find any closer symbol. Cheers Nick
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Rainer, > I wonder how best to handle this: bfd/elfxx-sparc.c > (_bfd_sparc_elf_relocate_section) already silently ignores the overflow in a > few select cases (like .stab sections), following the lead of Solaris ld. Do you know if the Solaris linker ignores overflow in other cases as well ? IE should we be emulating the Solaris linker and ignoring more overflows ? > As expected, the tests do PASS if I do this unconditionally for the > 3 affected relocs. > > This may or may not be a hack, though. It probably is a hack, modulo the answer to the question above of course. Are you able to examine a Solaris linked binary and find out how those relocs were resolved ? Ie is the debug info correct or corrupt or just uninitialised ? One possibility that occurs to me is that the Solaris linker is using a different linker script to the bfd linker (or whatever it uses) and so placing the sections in different places. Places which are more amenable to resolving the relocs. It also occurs to me that maybe the bug is in the assembler, in that it should be generating R_SPARC_UA64 relocs instead of R_SPARC_UA32 relocs. Not being a Solaris expert however, I do not know if this is the case. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26111] New: Attempting free on address which was not malloc()
https://sourceware.org/bugzilla/show_bug.cgi?id=26111 Bug ID: 26111 Summary: Attempting free on address which was not malloc() Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: 15664243668 at 163 dot com Target Milestone: 2.34 Created attachment 12616 --> https://sourceware.org/bugzilla/attachment.cgi?id=12616&action=edit PoC I have found a bug of attempting free on address which was not malloc() in function _bfd_coff_free_symbols by fuzzing, which is located in binutils-2.34/bfd/coffgen.c:1782. This bug is triggered as $objdump -d PoC We compile GNU Binutils-2.34 with AddressSanitizer in 32-bits on Ubuntu 16.04. The information are printed as: ./id:47,sig:06,src:001766,op:havoc,rep:4: file format pei-i386 Disassembly of section .text: <.text>: 0: ff 25 00 00 00 00 jmp*0x0 6: 90 nop 7: 90 nop = ==20459==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0xf3803b60 in thread T0 #0 0xf7275a84 in free (/usr/lib32/libasan.so.2+0x96a84) #1 0x867669f in _bfd_coff_free_symbols /home/ubuntu/yuetai/asan_programs/binutils-2.34/bfd/coffgen.c:1782 #2 0x867669f in _bfd_coff_close_and_cleanup /home/ubuntu/yuetai/asan_programs/binutils-2.34/bfd/coffgen.c:3180 #3 0x82b5784 in bfd_close_all_done /home/ubuntu/yuetai/asan_programs/binutils-2.34/bfd/opncls.c:789 #4 0x8059628 in display_file objdump.c:5016 #5 0x8059628 in main objdump.c:5349 #6 0xf703e636 in __libc_start_main (/lib32/libc.so.6+0x18636) #7 0x805ced5 (/home/ubuntu/yuetai/asan_target/binutils-2-34/objdump+0x805ced5) 0xf3803b60 is located 736 bytes inside of 1745-byte region [0xf3803880,0xf3803f51) allocated by thread T0 here: #0 0xf7275f8e in calloc (/usr/lib32/libasan.so.2+0x96f8e) #1 0x82a60ae in bfd_malloc /home/ubuntu/yuetai/asan_programs/binutils-2.34/bfd/libbfd.c:275 #2 0x82a60ae in bfd_zmalloc /home/ubuntu/yuetai/asan_programs/binutils-2.34/bfd/libbfd.c:360 #3 0x893dd8b (/home/ubuntu/yuetai/asan_target/binutils-2-34/objdump+0x893dd8b) SUMMARY: AddressSanitizer: bad-free ??:0 free ==20459==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26111] Attempting free on address which was not malloc()
https://sourceware.org/bugzilla/show_bug.cgi?id=26111 Alan Modra changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- Fixed for 2.35 *** This bug has been marked as a duplicate of bug 25447 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25447] objcopy : free() invalid pointer in _bfd_coff_free_symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25447 Alan Modra changed: What|Removed |Added CC||15664243668 at 163 dot com --- Comment #10 from Alan Modra --- *** Bug 26111 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #4 from Rainer Orth --- Created attachment 12617 --> https://sourceware.org/bugzilla/attachment.cgi?id=12617&action=edit ld-elf/eh5 elfdump -u output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #3 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- > Hi Rainer, > >> I wonder how best to handle this: bfd/elfxx-sparc.c >> (_bfd_sparc_elf_relocate_section) already silently ignores the overflow in a >> few select cases (like .stab sections), following the lead of Solaris ld. > > Do you know if the Solaris linker ignores overflow in other cases as well ? > IE should we be emulating the Solaris linker and ignoring more overflows ? I'd have to ask the Solaris linker engineer (Ali Bahrami, you may know him) that. I haven't found anything in the OpenSolaris linker sources, though. >> As expected, the tests do PASS if I do this unconditionally for the >> 3 affected relocs. >> >> This may or may not be a hack, though. > > It probably is a hack, modulo the answer to the question above of course. > > Are you able to examine a Solaris linked binary and find out how > those relocs were resolved ? Ie is the debug info correct or corrupt > or just uninitialised ? After linking the ld-elf/eh5 test with Solaris ld instead of ld-new, I tried the following: * Run readelf -u on the result, which comes up blank: The decoding of unwind sections for machine type Sparc v9 is not currently supported. * However, elfdump -u (the native Solaris ELF object dumping utility) produces results that seem at least well formed and possibly sensible (attached). * I've also run readelf -wf (also attached) and visually compared it to eh5.d (is there a manual way to perform a comparison between readelf etc. output and a .d file?): the first few sections seemed to match. > One possibility that occurs to me is that the Solaris linker is using > a different linker script to the bfd linker (or whatever it uses) and > so placing the sections in different places. Places which are more > amenable to resolving the relocs. The Solaris linker doesn't use explicit linker scripts (and has a different mapfile syntax compared to GNU ld). However, the internal rules (in the Solaris syntax) are documented in the Linkers and Libraries Guide: https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc > It also occurs to me that maybe the bug is in the assembler, in that it > should be generating R_SPARC_UA64 relocs instead of R_SPARC_UA32 relocs. > Not being a Solaris expert however, I do not know if this is the case. Me neither: I'm just the messenger ;-) Unfortunately, the Solaris/SPARC assembler doesn't support the .cfi_* directives, otherwise I could have tried to use it to assemble the input and compare. Are there C sources corresponding to the eh5*.s files that I could feed through Solaris/SPARC gcc configure to use as instead of gas? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #5 from Rainer Orth --- Created attachment 12618 --> https://sourceware.org/bugzilla/attachment.cgi?id=12618&action=edit ld-elf/eh5 readelf -wf output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=26103 --- Comment #2 from Markus Böck --- Created attachment 12619 --> https://sourceware.org/bugzilla/attachment.cgi?id=12619&action=edit Symbols in ios.o of the working compiler -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=26103 --- Comment #3 from Markus Böck --- Created attachment 12620 --> https://sourceware.org/bugzilla/attachment.cgi?id=12620&action=edit Symbols in ios.o of the compiler causing the assert in ld -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26103] Assertion failure at ldlang.c:7269 when compiling with LTO on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=26103 --- Comment #4 from Markus Böck --- Using git bisect I managed to figure out which commit of GCC 9 has started causing the issue. I am confused as to how or why it would do so however. The first commit that causes this bug is: "PR libstdc++/86450 use -Wabi=2 and simplify -Werror use" with revision number c3be340eb67fff7ef353d37bd02898f295ea0ef1 Regarding the reproducability I have used following configure options for building GCC 9: ../configure --target=x86_64-w64-mingw32 --disable-bootstrap --enable-version-specific-runtime-libs --with-gcc-major-version-only --prefix=/mnt/c/GCC-Build/NewestLinux --with-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --with-tune=znver1 --with-cross-host --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-nls --disable-win32-registry --enable-shared --with-gnu-ld --program-prefix=x86_64-w64-mingw32- --enable-threads=posix --enable-__cxa_atexit --enable-libgomp --with-gnu-as --program-suffix=-9 --without-isl All tests that I performed have been using the same version of MinGW (close to current trunk) as well as the binutils at the revision specified in the original post. Additionally I ran gdb to check which symbol cause the re-inclusion of libstdc++. The function with the assert 'ldlang_add_file' is called by 'add_archive_element', whose name parameter has following content: ".weak._ZSt4swapISt6localeENSt9enable_ifIXsrSt6__and_IISt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS5_ESt18is_move_assignableIS5_EEE5valueEvE4typeERS5_SF_._ZStanSt12_Ios_IostateS_" Last I tried to print and compare the symbol table of ios.o both before and after the bad commit. I ran llvm-objdump -t on both versions of libstdc++ and removed all other object files but ios.o in the output. Only the object file after the bad commit contains .weak symbols that might trip up the linker. I have attached both symbols tables of the working compiler and the one triggering the assert. Please tell me if there is anything more that I can do for you and thank you for your patience and time already spent! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] New: readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 Bug ID: 26112 Summary: readelf --debug-dump=macro can't parse clang debug info Product: binutils Version: 2.34 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tstellar at redhat dot com Target Milestone: --- Created attachment 12621 --> https://sourceware.org/bugzilla/attachment.cgi?id=12621&action=edit Clang binary output. Test case: $ echo "#define FOO bar" | clang -x c -c - -fdebug-macro -gdwarf-5 -o clang-debug-macro.o $ readelf --debug-dump=macro ./clang-debug-macro.o Contents of the .debug_macro section: Offset: 0x0 Version: 5 Offset size: 4 Offset into .debug_line: 0x0 DW_MACRO_start_file - lineno: 0 filenum: 1 readelf: ./clang-debug-macro.o: Error: Unknown macro opcode 0b seen I'm using binutils-2.34.0-6.fc33 from Fedora and clang 11 (which is current trunk). It looks this used to work, but stopped working after clang commit: https://github.com/llvm/llvm-project/commit/b47403c0a4c532554cf3d67ed1669fe00530aab3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26113] New: gas 2.34 gets stuck in infinite loop after compilation error
https://sourceware.org/bugzilla/show_bug.cgi?id=26113
Bug ID: 26113
Summary: gas 2.34 gets stuck in infinite loop after compilation
error
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: me at tbrindus dot ca
Target Milestone: ---
Created attachment 12622
--> https://sourceware.org/bugzilla/attachment.cgi?id=12622&action=edit
Python source code
Hi,
We run a system where students may submit code in several languages and have it
run on our machines -- among others, we support x64 Assembly and Python. One
student mis-selected the language of their source code, and submitted a Python
program as x64 Assembly. This caused gas 2.34 to lock up after emitting the
expected syntax errors; it did not terminate after 8 hours (when we found out
and SIGKILL'd the process).
We are running gas from Debian sid's repos. In particular:
$ x86_64-linux-gnu-as --version
GNU assembler (GNU Binutils for Debian) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
The file submitted is attached. Running gas with no extra arguments exhibits
the issue.
$ x86_64-linux-gnu-as test.py
test.py: Assembler messages:
test.py:1: Error: no such instruction: `def cal():'
test.py:2: Error: junk at end of line, first unrecognized character is `('
test.py:4: Error: invalid character '(' in mnemonic
...snip...
test.py:17: Error: invalid character '(' in mnemonic
test.py: Error: symbol definition loop encountered at `int'
test.py: Error: invalid operands (.text and *ABS* sections) for `%' when
setting `a'
^C
This appears to be a regression since 2.31.1 (Debian buster version of gas),
which exits after emitting the error messages.
I'm happy to provide any other information that may be useful.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26113] gas 2.34 gets hangs after compilation error
https://sourceware.org/bugzilla/show_bug.cgi?id=26113 Tudor changed: What|Removed |Added Summary|gas 2.34 gets stuck in |gas 2.34 gets hangs after |infinite loop after |compilation error |compilation error | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26113] gas 2.34 hangs after compilation error
https://sourceware.org/bugzilla/show_bug.cgi?id=26113 Tudor changed: What|Removed |Added Summary|gas 2.34 gets hangs after |gas 2.34 hangs after |compilation error |compilation error -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26113] gas 2.34 hangs after compilation error
https://sourceware.org/bugzilla/show_bug.cgi?id=26113 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Alan Modra --- This was fixed on master with commit 2a50b40146 and on binutils-2_34-branch with commit 5768460022. -- You are receiving this mail because: You are on the CC list for the bug.
