[Bug binutils/26086] New: objdump: SIGSEGV in process_debug_info
https://sourceware.org/bugzilla/show_bug.cgi?id=26086 Bug ID: 26086 Summary: objdump: SIGSEGV in process_debug_info Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: will4619 at gmail dot com Target Milestone: --- Created attachment 12593 --> https://sourceware.org/bugzilla/attachment.cgi?id=12593&action=edit crash file Build git master with command: CC=clang CXX=clang++ CFLAGS+="-g -fsanitize=address" CXXFLAGS+="-g -fsanitize=address" ./configure; make all-binutils OS: Ubuntu 18.04.1 Kernel : 5.3.0-53-generic Command to reproduce crash: ./objdump -g crash_0 ASAN report: AddressSanitizer:DEADLYSIGNAL = ==6156==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 (pc 0x004e8104 bp 0x7ffe159c4d00 sp 0x7ffe159c4280 T0) ==6156==The signal is caused by a WRITE memory access. ==6156==Hint: address points to the zero page. #0 0x4e8103 in process_debug_info /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/dwarf.c #1 0x50c515 in display_debug_types /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/dwarf.c:6546:10 #2 0x4ce47e in dump_dwarf_section /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:3766:6 #3 0x651a0d in bfd_map_over_sections /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/bfd/section.c:1379:5 #4 0x4ca62a in dump_dwarf /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:3804:3 #5 0x4c8342 in dump_bfd /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:4918:4 #6 0x4c7293 in display_object_bfd /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:4955:7 #7 0x4c7181 in display_any_bfd /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:5045:5 #8 0x4c6ce8 in display_file /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:5066:3 #9 0x4c603e in main /home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/./objdump.c:5412:6 #10 0x7f01d700cb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #11 0x41ba29 in _start (/home/wt/SQLab/Target/Eva/Fuzz_binutil/binutils_master/binutils/objdump+0x41ba29) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26087] New: objdump --reloc does not work
https://sourceware.org/bugzilla/show_bug.cgi?id=26087 Bug ID: 26087 Summary: objdump --reloc does not work Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: martin at dev2day dot de Target Milestone: --- Created attachment 12594 --> https://sourceware.org/bugzilla/attachment.cgi?id=12594&action=edit file that I used to run objdump and readelf as described in the Description field Hello! When running obdjump on the attached file I get the following (empty) output: $ objdump --reloc relocoverwrite relocoverwrite: file format elf64-x86-64 When I run readelf I get the following output: $ readelf --relocs relocoverwrite Relocation section '.rela.dyn' at offset 0x5c0 contains 11 entries: Offset Info Type Sym. ValueSym. Name + Addend 3de0 0008 R_X86_64_RELATIVE1240 3de8 0008 R_X86_64_RELATIVE11f0 4048 0008 R_X86_64_RELATIVE4048 3fd0 00010006 R_X86_64_GLOB_DAT _ITM_deregisterTMClone + 0 3fd8 000d0006 R_X86_64_GLOB_DAT printf@GLIBC_2.2.5 + 0 3fe0 00050006 R_X86_64_GLOB_DAT __libc_start_main@GLIBC_2.2.5 + 0 3fe8 00060006 R_X86_64_GLOB_DAT __gmon_start__ + 0 3ff0 00090006 R_X86_64_GLOB_DAT _ITM_registerTMCloneTa + 0 3ff8 000a0006 R_X86_64_GLOB_DAT __cxa_finalize@GLIBC_2.2.5 + 0 4050 000b0005 R_X86_64_COPY 4050 stdout@GLIBC_2.2.5 + 0 4060 000c0005 R_X86_64_COPY 4060 stdin@GLIBC_2.2.5 + 0 Relocation section '.rela.plt' at offset 0x6c8 contains 5 entries: Offset Info Type Sym. ValueSym. Name + Addend 4018 00020007 R_X86_64_JUMP_SLO puts@GLIBC_2.2.5 + 0 4020 00030007 R_X86_64_JUMP_SLO __stack_chk_fail@GLIBC_2.4 + 0 4028 00040007 R_X86_64_JUMP_SLO read@GLIBC_2.2.5 + 0 4030 00070007 R_X86_64_JUMP_SLO setvbuf@GLIBC_2.2.5 + 0 4038 00080007 R_X86_64_JUMP_SLO __isoc99_scanf@GLIBC_2.7 + 0 It seems that objdump is not able to read the relocation entries. I tested this on Ubuntu 20.04 and Fedora 32. Same behavior. Best Martin -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 Ralf Habacker changed: What|Removed |Added CC||ralf.habacker at freenet dot de --- Comment #5 from Ralf Habacker --- Created attachment 12595 --> https://sourceware.org/bugzilla/attachment.cgi?id=12595&action=edit 0001-Fix-parse-error-in-the-Windows-resource-parser.patch Patch which fixes the remaining parse error. It was initial added to https://bugzilla.opensuse.org/show_bug.cgi?id=920134 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 --- Comment #6 from Ralf Habacker --- Created attachment 12596 --> https://sourceware.org/bugzilla/attachment.cgi?id=12596&action=edit 0002-Fix-catching-EOF-in-the-Windows-resource-parser.patch This patch fixes the remaining, not catched EOF conditions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26088] New: windmc reports incorrect line numbers
https://sourceware.org/bugzilla/show_bug.cgi?id=26088 Bug ID: 26088 Summary: windmc reports incorrect line numbers Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ralf.habacker at freenet dot de Target Milestone: --- Created attachment 12597 --> https://sourceware.org/bugzilla/attachment.cgi?id=12597&action=edit sample.mc - test file windmc returns wrong line number on processing the appended file. The file contains a syntax error in line 30 30: Language+German which is reported as In sample.mc at line 27: parser: syntax error. In sample.mc at line 27: fatal: missing '=' for Language. How to reproduce: 1. checkout binutils sources 2. configure on linux with 'configure --with-windmc' 3. download the appended file 4. run 'binutils/windmc sample.mc' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26088] windmc reports incorrect line numbers
https://sourceware.org/bugzilla/show_bug.cgi?id=26088 --- Comment #1 from Ralf Habacker --- Created attachment 12598 --> https://sourceware.org/bugzilla/attachment.cgi?id=12598&action=edit 0003-Corrects-the-broken-line-number-incrementation-in-th.patch Patch which corrects the broken line number incrementation in the Windows resource parser -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26088] windmc reports incorrect line numbers
https://sourceware.org/bugzilla/show_bug.cgi?id=26088 Ralf Habacker changed: What|Removed |Added Depends on||26082 --- Comment #2 from Ralf Habacker --- This patch depends on the patches appended to bug 26082. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=26082 [Bug 26082] infinite loop in windmc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 Ralf Habacker changed: What|Removed |Added Blocks||26088 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=26088 [Bug 26088] windmc reports incorrect line numbers -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26082] infinite loop in windmc
https://sourceware.org/bugzilla/show_bug.cgi?id=26082 --- Comment #7 from Joel Anderson --- I do think that it is important to note that the two new patches alter windmc behavior to accept a file where the period is immediately followed by a EOF instead of a newline or carriage return and newline. These types of files are rejected by current versions of mc.exe, which is what I was using the 'premature EOF' attachment to test against myself. While the new patches are more forgiving to the user and perhaps a better way to handle the scenario, they do not match mc.exe behavior. I can see arguments for both cases, but just want to make sure that it is a deliberate choice to deviate windmc's behavior from that of mc.exe. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26002] ld: Should an unversioned undefined symbol use VER_NDX_GLOBAL instead of VER_NDX_LOCAL?
https://sourceware.org/bugzilla/show_bug.cgi?id=26002 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-06-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Alan Modra --- > Should `g` be VER_NDX_GLOBAL instead of VER_NDX_LOCAL? Yes, it probably should be. Note that there are cases where VER_NDX_LOCAL is expected, but this doesn't seem to be one of those cases. See https://docs.oracle.com/cd/E26505_01/html/E26506/chapter6-54676.html -- You are receiving this mail because: You are on the CC list for the bug.
