[Bug binutils/15152] readelf and objdump don't print strings from .dwz file
https://sourceware.org/bugzilla/show_bug.cgi?id=15152 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dda8d76d0dd2b07df769f6cae20aff483468b342 commit dda8d76d0dd2b07df769f6cae20aff483468b342 Author: Nick Clifton Date: Wed Nov 15 11:34:03 2017 + Add support to readelf and objdump for following links to separate debug information files. Hi Guys, I am applying the rather large patch attached to this email to enhance the readelf and objdump programs so that they now have the ability to follow links to separate debug info files. (As requested by PR 15152). So for example whereas before we had this output: $ readelf -wi main.exe Contents of the .debug_info section: [...] <15> DW_AT_comp_dir: (alt indirect string, offset: 0x30c) [...] With the new option enabled we get: $ readelf -wiK main.exe main.exe: Found separate debug info file: dwz.debug Contents of the .debug_info section (loaded from main.exe): [...] <15> DW_AT_comp_dir: (alt indirect string, offset: 0x30c) /home/nickc/Downloads/dwzm [...] The link following feature also means that we can get two lots of output if the same section exists in both the main file and the separate debug info file: $ readelf -wiK main.exe main.exe: Found separate debug info file: dwz.debug Contents of the .debug_info section (loaded from main.exe): [...] Contents of the .debug_info section (loaded from dwz.debug): [...] The patch also adds the ability to display the contents of debuglink sections: $ readelf -wk main.exe Contents of the .gnu_debugaltlink section: Separate debug info file: dwz.debug Build-ID (0x14 bytes): c4 a8 89 8d 64 cf 70 8a 35 68 21 f2 ed 24 45 3e 18 7a 7a 93 Naturally there are long versions of these options (=follow-links and =links). The documentation has been updated as well, and since both readelf and objdump use the same set of debug display options, I have moved the text into a separate file. There are also a couple of new binutils tests to exercise the new behaviour. There are a couple of missing features in the current patch however, although I do intend to address them in follow up submissions: Firstly the code does not check the build-id inside separate debug info files when it is searching for a file specified by a .gnu_debugaltlink section. It just assumes that if the file is there, then it contains the information being sought. Secondly I have not checked the DWARF-5 version of these link features, so there will probably be code to add there. Thirdly I have only implemented link following for the DW_FORM_GNU_strp_alt format. Other alternate formats (eg DW_FORM_GNU_ref_alt) have yet to be implemented. Lastly, whilst implementing this feature I found it necessary to move some of the global variables used by readelf (eg section_headers) into a structure that can be passed around. I have moved all of the global variables that were necessary to get the patch working, but I need to complete the operation and move the remaining, file-specific variables (eg dynamic_strings). Cheers Nick binutilsPR 15152 * dwarf.h (enum dwarf_section_display_enum): Add gnu_debuglink, gnu_debugaltlink and separate_debug_str. (struct dwarf_section): Add filename field. Add prototypes for load_separate_debug_file, close_debug_file and open_debug_file. * dwarf.c (do_debug_links): New. (do_follow_links): New. (separate_debug_file, separate_debug_filename): New. (fetch_alt_indirect_string): New function. Retrieves a string from the debug string table in the separate debug info file. (read_and_display_attr_value): Use it with DW_FORM_GNU_strp_alt. (load_debug_section_with_follow): New function. Like load_debug_section, but if the first attempt fails, then tries again in the separate debug info file. (introduce): New function. (process_debug_info): Use load_debug_section_with_follow and introduce. (load_debug_info): Likewise. (display_debug_lines_raw): Likewise. (display_debug_lines_decoded): Likewise. (display_debug_macinfo): Likewise. (display_debug_macro): Likewise. (display_debug_abbrev): Likewise. (display_debug_loc): Likewise. (display_debug_str): Likewise. (display_debug_aranges): Likewise. (display_debug_addr); Likewise. (display_debug_frames): Likewise. (display_gdb_index): Likewis
[Bug binutils/15152] readelf and objdump don't print strings from .dwz file
https://sourceware.org/bugzilla/show_bug.cgi?id=15152 Nick Clifton changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Nick Clifton --- Hi Tom, Please try out the latest binutils sources and let me know if this is what you were hoping for. (Use the -WK option to objdump to have it follow the link to the .dwz file). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22426] objcopy crashes with fabricated file
https://sourceware.org/bugzilla/show_bug.cgi?id=22426 --- Comment #4 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=be74fad95edc8827516e144cf38d135b503249cd commit be74fad95edc8827516e144cf38d135b503249cd Author: Alan Modra Date: Wed Nov 15 22:23:22 2017 +1030 objcopy memory leak PR 22426 * objcopy.c (copy_main): Free tmpname. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22426] objcopy crashes with fabricated file
https://sourceware.org/bugzilla/show_bug.cgi?id=22426 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Both of these results are normal expected outcomes. An error message is not a "crash", and out of memory can easily happen, especially when binutils is compiled 32-bit. The memory leak is easily fixed, so that's done. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22441] x86-64: wrong relocation type used for 32-bit index-with-no-base addressing
https://sourceware.org/bugzilla/show_bug.cgi?id=22441 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22272] Output of testsuite/gas/all/fill-1.s isn't verified
https://sourceware.org/bugzilla/show_bug.cgi?id=22272 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.30 --- Comment #1 from H.J. Lu --- Fixed as of commit 94092126a05ee625bf05d48cb331472b8f87d235 Author: Alan Modra Date: Wed Oct 25 15:31:58 2017 +1030 Yet another fill-1 test fix -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22443] New: Global buffer overflow in _bfd_elf_get_symbol_version_string
https://sourceware.org/bugzilla/show_bug.cgi?id=22443 Bug ID: 22443 Summary: Global buffer overflow in _bfd_elf_get_symbol_version_string Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mgcho.minic at gmail dot com Target Milestone: --- Created attachment 10591 --> https://sourceware.org/bugzilla/attachment.cgi?id=10591&action=edit poc file Triggered by "./objdump -x $POC" Tested on Ubuntu 16.04 (x86) Global buffer overflow is occured when corrupted processing elf file. Configuration information: CC=clang CXX=clang++ CFLAGS="-g -O0 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=all" CXXFLAGS=-fsanitize="-g -O0 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=all" ./configure ASAN output: ==14558==ERROR: AddressSanitizer : global-buffer-overflow on address 0x08626220 at pc 0x082dd706 bp 0xbfeb88a8 sp 0xbfeb889c READ of size 2 at 0x08626220 thread T0 #0 0x82dd705 in _bfd_elf_get_symbol_version_string /home/min/fuzzing/src/binutils/binutils-gdb/bfd/elf.c:1838:59 #1 0x8149baf in objdump_print_symname /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:892:22 #2 0x814f52f in disassemble_bytes /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:2050:7 #3 0x814f52f in disassemble_section /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:2319 #4 0x8279497 in bfd_map_over_sections /home/min/fuzzing/src/binutils/binutils-gdb/bfd/section.c:1395:5 #5 0x8144976 in disassemble_data /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:2455:3 #6 0x8144976 in dump_bfd /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:3554 #7 0x8142d75 in display_object_bfd /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:3611:7 #8 0x8142d75 in display_any_bfd /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:3700 #9 0x8141fe4 in display_file /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:3721:3 #10 0x8141fe4 in main /home/min/fuzzing/src/binutils/binutils-gdb/binutils/./objdump.c:4023 #11 0xb7494636 in __libc_start_main /build/glibc-KM3i_a/glibc-2.23/csu/../csu/libc-start.c:291 #12 0x806c687 in _start (/home/min/fuzzing/program/binutils-master-patch/bin/objdump+0x806c687) 0x08626220 is located 32 bytes to the left of global variable '' defined in 'section.c:771:3' (0x8626240) of size 6 '' is ascii string '*UND*' 0x08626220 is located 0 bytes to the right of global variable 'global_syms' defined in 'section.c:758:22' (0x86261c0) of size 96 SUMMARY: AddressSanitizer: global-buffer-overflow /home/min/fuzzing/src/binutils/binutils-gdb/bfd/elf.c:1838:59 in _bfd_elf_get_symbol_version_string Credits: Mingi Cho and Taekyoung Kwon of the Information Security Lab, Yonsei University. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22444] New: Incorrect note padding check
https://sourceware.org/bugzilla/show_bug.cgi?id=22444 Bug ID: 22444 Summary: Incorrect note padding check Product: binutils Version: 2.30 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- readelf.c has inote.type = BYTE_GET (external->type); inote.namesz = BYTE_GET (external->namesz); inote.namedata = external->name; inote.descsz = BYTE_GET (external->descsz); inote.descdata = inote.namedata + align_power (inote.namesz, 2); inote.descpos = offset + (inote.descdata - (char *) pnotes); next = inote.descdata + align_power (inote.descsz, 2); This is incorrect. According to gABI: namesz and name The first namesz bytes in name contain a null-terminated character representation of the entry's owner or originator. There is no formal mechanism for avoiding name conflicts. By convention, vendors use their own name, such as XYZ Computer Company, as the identifier. If no name is present, namesz contains 0. Padding is present, if necessary, to ensure 8 or 4-byte alignment for the descriptor (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in namesz. descsz and desc The first descsz bytes in desc hold the note descriptor. The ABI places no constraints on a descriptor's contents. If no descriptor is present, descsz contains 0. Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz. Here the name field, not namesz, is padded for the note descriptor. And the desc field, not descsz, is padded for the next note entry. But on Linux, .note.ABI-tag and .note.gnu.build-id notes are always aligned to 4 bytes. In this case, we should check sh_addralign, instead of using alignment based on 32-bit or 64-bit objects. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22444] Incorrect note padding check
https://sourceware.org/bugzilla/show_bug.cgi?id=22444 --- Comment #1 from H.J. Lu --- elf.c has the same issue: /* FIXME: bad alignment assumption. */ Elf_External_Note *xnp = (Elf_External_Note *) p; Elf_Internal_Note in; if (offsetof (Elf_External_Note, name) > buf - p + size) return FALSE; in.type = H_GET_32 (abfd, xnp->type); in.namesz = H_GET_32 (abfd, xnp->namesz); in.namedata = xnp->name; if (in.namesz > buf - in.namedata + size) return FALSE; in.descsz = H_GET_32 (abfd, xnp->descsz); in.descdata = in.namedata + BFD_ALIGN (in.namesz, 4); in.descpos = offset + (in.descdata - buf); -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22444] Incorrect note padding check
https://sourceware.org/bugzilla/show_bug.cgi?id=22444 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22444] Incorrect note padding check
https://sourceware.org/bugzilla/show_bug.cgi?id=22444 --- Comment #2 from Florian Weimer --- Can we really change this in binutils and glibc at this point? Don't we have to change the gabi documentation instead? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
