[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.
https://sourceware.org/bugzilla/show_bug.cgi?id=28417
--- Comment #4 from Jonathan Wakely ---
Yes, the patch is correct.
To construct an empty string either use "" as the initializer, or just use the
default constructor. Creating a string from NULL or nullptr is completely bogus
and has been undefined behaviour since C++98:
basic_string(const charT* s, const Allocator& a = Allocator());
Requires: s shall not be a null pointer.
And GCC's std::string has turned that into an exception since forever:
// NB: Not required, but considered best practice.
if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end)
std::__throw_logic_error(__N("basic_string::"
"_M_construct null not valid"));
Which suggests neither of these pieces of code ever executes, so could be
removed.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28399] Flag to order functions in a specific order based on order file
https://sourceware.org/bugzilla/show_bug.cgi?id=28399 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to hiraditya from comment #0) > The BSD linker has this option `--symbol-ordering-file=file ` > that lays out functions (and possibly other symbols) in the order specified > in order file. The documentation does not appear to specify the format of the file, nor what happens to symbols that are not in the file, or symbols that are in the file but which do not appear in any of the input files. (Or what happens to weak symbols, or aliases or ...) Basically it does not appear to be very well documented. > I can't find similar flag in gnu ld. There is none. But ... you can use linker scripts to achieve a similar effect - at least on an object file basis, rather than a symbol basis. In linker scripts you can specify the order in which input sections will appear in the output section, so you can choose for example to have .text from foo.o appear first, followed by .text from bar.o, followed by any remaining .text sections from any remaining input files. Other than that though you are right, ld does not have this facility. Of course if someone wants to write a patch to implement it, I will be happy to review it... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28420] New: segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 Bug ID: 28420 Summary: segv in objdump at disassemble_bytes objdump.c:3059 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: irfanariq at kaist dot ac.kr Target Milestone: --- Created attachment 13703 --> https://sourceware.org/bugzilla/attachment.cgi?id=13703&action=edit poc and full stack trace Hello, We are currently working on fuzz testing feature, and we found a **SEGV** on `objdump`. The stack traces are as follow: ```st ==2673==ERROR: AddressSanitizer: SEGV on unknown address 0x071a5d68 (pc 0x55ca946b0f38 bp 0x7ffd51b38d50 sp 0x7ffd51b38b00 T0) ==2673==The signal is caused by a READ memory access. #0 0x55ca946b0f37 in disassemble_bytes objdump.c:3059 #1 0x55ca946b3342 in disassemble_section objdump.c:3455 #2 0x55ca94b7e3c0 in bfd_map_over_sections .../binutils-git/bfd/section.c:1383 #3 0x55ca946b4293 in disassemble_data objdump.c:3599 #4 0x55ca946bb6cc in dump_bfd objdump.c:5006 #5 0x55ca946bb994 in display_object_bfd objdump.c:5068 #6 0x55ca946bbd2f in display_any_bfd objdump.c:5158 #7 0x55ca946bbda6 in display_file objdump.c:5179 #8 0x55ca946bd15a in main objdump.c:5529 ``` The full stack trace is attached. **Step to reproduce** We configured `objdump` using `CFLAGS="-g -O0 -fsanitize=address" ./configure --prefix=$(pwd)/ --disable-shared --enable-targets=all` and build it using `make -j 10`, and run it with: ``` ./objdump --reloc -a -r 32 ld -Ttext -d ``` The input file is attached. **Environment** - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - binutils version: commit (98ca73a) of master branch on sourceware git ([link](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=98ca73afe51e1e921915c37f242c88d4d445841c)) Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28419] New: global-buffer-overflow in objdump at objdump.c:3054
https://sourceware.org/bugzilla/show_bug.cgi?id=28419 Bug ID: 28419 Summary: global-buffer-overflow in objdump at objdump.c:3054 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: irfanariq at kaist dot ac.kr Target Milestone: --- Created attachment 13702 --> https://sourceware.org/bugzilla/attachment.cgi?id=13702&action=edit poc and full stack trace Hello, We are currently working on fuzz testing feature, and we found a **global-buffer-overflow** on `objdump`. The stack traces are as follow: ```st ==2709==ERROR: AddressSanitizer: global-buffer-overflow on address 0x5588a4712830 at pc 0x5588a22d7e13 bp 0x7fff1a598410 sp 0x7fff1a598400 READ of size 8 at 0x5588a4712830 thread T0 #0 0x5588a22d7e12 in disassemble_bytes objdump.c:3054 #1 0x5588a22da342 in disassemble_section objdump.c:3455 #2 0x5588a27a53c0 in bfd_map_over_sections .../binutils-git/bfd/section.c:1383 #3 0x5588a22db293 in disassemble_data objdump.c:3599 #4 0x5588a22e26cc in dump_bfd objdump.c:5006 #5 0x5588a22e2994 in display_object_bfd objdump.c:5068 #6 0x5588a22e2d2f in display_any_bfd objdump.c:5158 #7 0x5588a22e2da6 in display_file objdump.c:5179 #8 0x5588a22e415a in main objdump.c:5529 ``` The full stack trace is attached. **Step to reproduce** We configured `objdump` using `CFLAGS="-g -O0 -fsanitize=address" ./configure --prefix=$(pwd)/ --disable-shared --enable-targets=all` and build it using `make -j 10`, and run it with: ``` ./objdump data16 -marm i8086 64 -Ttext --headers ppcps --debugging --wide --demangle 440 --dwarf --file-offsets --line-numbers --disassemble nm -d -Wa ``` The input file is attached. **Environment** - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - binutils version: commit (98ca73a) of master branch on sourceware git ([link](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=98ca73afe51e1e921915c37f242c88d4d445841c)) Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28422] New: use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 Bug ID: 28422 Summary: use-after-free in objdump at get_build_id (./bfd/opncls.c:1864) Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: irfanariq at kaist dot ac.kr Target Milestone: --- Created attachment 13705 --> https://sourceware.org/bugzilla/attachment.cgi?id=13705&action=edit poc and full stack trace Hello, We are currently working on fuzz testing feature, and we found a **use-after-free** on `objdump`. The stack traces are as follow: ```st ==4270==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210b910 at pc 0x55636bb42284 bp 0x7ffd4bf612d0 sp 0x7ffd4bf612c0 READ of size 8 at 0x6210b910 thread T0 #0 0x55636bb42283 in get_build_id .../binutils-git/bfd/opncls.c:1864 #1 0x55636bb4285f in get_build_id_name .../binutils-git/bfd/opncls.c:1972 #2 0x55636bb413b6 in find_separate_debug_file .../binutils-git/bfd/opncls.c:1463 #3 0x55636bb42cd1 in bfd_follow_build_id_debuglink .../binutils-git/bfd/opncls.c:2087 #4 0x55636bc8b15d in _bfd_dwarf2_slurp_debug_info dwarf2.c:4684 #5 0x55636bc8c722 in _bfd_dwarf2_find_nearest_line dwarf2.c:4985 #6 0x55636bf1fbec in _bfd_mips_elf_find_nearest_line .../binutils-git/bfd/elfxx-mips.c:13061 #7 0x55636b6705fa in show_line objdump.c:1784 #8 0x55636b675478 in disassemble_bytes objdump.c:2770 #9 0x55636b679342 in disassemble_section objdump.c:3455 #10 0x55636bb443c0 in bfd_map_over_sections .../binutils-git/bfd/section.c:1383 ``` The full stack trace is attached. **Step to reproduce** We configured `objdump` using `CFLAGS="-g -O0 -fsanitize=address" ./configure --prefix=$(pwd)/ --disable-shared --enable-targets=all` and build it using `make -j 10`, and run it with: ``` .../binutils-git/install_asan/bin/objdump -S ``` The input file is attached. **Environment** - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - binutils version: commit (98ca73a) of master branch on sourceware git ([link](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=98ca73afe51e1e921915c37f242c88d4d445841c)) Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28399] Flag to order functions in a specific order based on order file
https://sourceware.org/bugzilla/show_bug.cgi?id=28399 --- Comment #2 from hiraditya --- > the format of the file it is a text file with line separated (mangled) symbol name. > nor what happens to symbols that are not in the file IIUC symbols that are in the file get preference over all other symbols > or symbols that are in the file but which do not appear in any of the input > files. Those symbols get ignored. And can be printed with -order_file_statistics flag > (Or what happens to weak symbols, or aliases or ...) I think the linker may print warning in case of duplicates. but it can take any conservative approach. I forgot to mention that MacOS linker also has similar functionality. Here is relevant output from `man ld` on Mac OS -order_file file Alters the order in which functions and data are laid out. For each section in the output file, any symbol in that section that are specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leaf name and a colon (e.g. foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (e.g. ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Literal c-strings may be ordered by by quoting the string (e.g. "Hello, world\n") in the order file. -no_order_inits When the -order_file option is not used, the linker lays out functions in object file order and it moves all initializer routines to the start of the __text section and terminator routines to the end. Use this option to disable the automatic rearrangement of initializers and terminators. -exported_symbols_order file When targeting Mac OS X 10.6 or later, the format of the exported symbol information can be optimized to make lookups of popular symbols faster. This option is used to pass a file containing a list of the sym- bols most frequently used by clients of the dynamic library being built. Not all exported symbols need to be listed. -order_file_statistics Logs information about the processing of a -order_file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28399] Flag to order functions in a specific order based on order file
https://sourceware.org/bugzilla/show_bug.cgi?id=28399 --- Comment #3 from hiraditya --- Here is an example of order file that is used to build clang itself. https://opensource.apple.com/source/clang/clang-211.10.1/clang.order.auto.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28421] New: SEGV in objdump at dump_reloc_set objdump.c:4636
https://sourceware.org/bugzilla/show_bug.cgi?id=28421 Bug ID: 28421 Summary: SEGV in objdump at dump_reloc_set objdump.c:4636 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: irfanariq at kaist dot ac.kr Target Milestone: --- Created attachment 13704 --> https://sourceware.org/bugzilla/attachment.cgi?id=13704&action=edit poc and full stack trace Hello, We are currently working on fuzz testing feature, and we found a **SEGV** on `objdump`. The stack traces are as follow: ```st ==4014==ERROR: AddressSanitizer: SEGV on unknown address 0x0550 (pc 0x561292377be8 bp 0x77d72700 sp 0x77d724c0 T0) ==4014==The signal is caused by a READ memory access. #0 0x561292377be7 in dump_reloc_set objdump.c:4636 #1 0x561292378721 in dump_relocs_in_section objdump.c:4768 #2 0x56129283c3c0 in bfd_map_over_sections .../binutils-git/bfd/section.c:1383 #3 0x561292378767 in dump_relocs objdump.c:4777 #4 0x561292379672 in dump_bfd objdump.c:5000 #5 0x561292379994 in display_object_bfd objdump.c:5068 #6 0x561292379d2f in display_any_bfd objdump.c:5158 #7 0x561292379da6 in display_file objdump.c:5179 #8 0x56129237b15a in main objdump.c:5529 #9 0x7fdb7b7e4bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6) #10 0x561292361ac9 in _start (.../binutils-git/install_asan/bin/objdump+0xdaeac9) ``` The full stack trace is attached. **Step to reproduce** We configured `objdump` using `CFLAGS="-g -O0 -fsanitize=address" ./configure --prefix=$(pwd)/ --disable-shared --enable-targets=all` and build it using `make -j 10`, and run it with: ``` ./objdump -x ``` The input file is attached. **Environment** - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - binutils version: commit (98ca73a) of master branch on sourceware git ([link](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=98ca73afe51e1e921915c37f242c88d4d445841c)) Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28423] New: use-after-free in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28423 Bug ID: 28423 Summary: use-after-free in objdump at disassemble_bytes objdump.c:3059 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: irfanariq at kaist dot ac.kr Target Milestone: --- Created attachment 13706 --> https://sourceware.org/bugzilla/attachment.cgi?id=13706&action=edit poc and full stack trace Hello, We are currently working on fuzz testing feature, and we found a **use-after-free** on `objdump`. The stack traces are as follow: ```st ==2689==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200190 at pc 0x560e3bcdef38 bp 0x7ffe07f66680 sp 0x7ffe07f66670 READ of size 8 at 0x60200190 thread T0 #0 0x560e3bcdef37 in disassemble_bytes objdump.c:3059 #1 0x560e3bce1342 in disassemble_section objdump.c:3455 #2 0x560e3c1ac3c0 in bfd_map_over_sections .../binutils-git/bfd/section.c:1383 #3 0x560e3bce2293 in disassemble_data objdump.c:3599 #4 0x560e3bce96cc in dump_bfd objdump.c:5006 #5 0x560e3bce9994 in display_object_bfd objdump.c:5068 #6 0x560e3bce9d2f in display_any_bfd objdump.c:5158 #7 0x560e3bce9cd9 in display_any_bfd objdump.c:5139 #8 0x560e3bce9da6 in display_file objdump.c:5179 #9 0x560e3bceb15a in main objdump.c:5529 ``` The full stack trace is attached. **Step to reproduce** We configured `objdump` using `CFLAGS="-g -O0 -fsanitize=address" ./configure --prefix=$(pwd)/ --disable-shared --enable-targets=all` and build it using `make -j 10`, and run it with: ``` ./objdump data16 -marm i8086 64 -Ttext --headers ppcps --debugging --wide --demangle 440 --dwarf --file-offsets --line-numbers --disassemble nm -d -Wa ``` The input file is attached. **Environment** - OS: Ubuntu 18.04.5 LTS - GCC version: gcc 7.5.0 - binutils version: commit (98ca73a) of master branch on sourceware git ([link](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=98ca73afe51e1e921915c37f242c88d4d445841c)) Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28401] fail to allocate error in objdump at xmalloc.c:147
https://sourceware.org/bugzilla/show_bug.cgi?id=28401 --- Comment #1 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=55e3926e79937da55da3eaad3b15b4c099071976 commit 55e3926e79937da55da3eaad3b15b4c099071976 Author: Alan Modra Date: Wed Oct 6 09:54:56 2021 +1030 PR28401, invalid section name lookup The PR28401 testcase has a section named "", ie. an empty string. This results in some silly behaviour in load_debug_section, and dump_dwarf_section. Fix that. Note that this patch doesn't correct the main complaint in PR28401, "failed to allocate", since malloc failures on sections having huge bogus sizes are to be expected. We can't safely catch all such cases by comparing with file size, for example, where sections contain compressed data. PR 28401 * objdump.c (load_debug_section): Don't attempt to retrieve empty name sections. (dump_dwarf_section): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28403] segv in objdump at disassemble_bytes (objdump.c:3055)
https://sourceware.org/bugzilla/show_bug.cgi?id=28403 --- Comment #1 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=0a6041ce9383338fa62acb207683780faaa8b42c commit 0a6041ce9383338fa62acb207683780faaa8b42c Author: Alan Modra Date: Wed Oct 6 10:17:29 2021 +1030 PR28403, null pointer dereference in disassemble_bytes Indexing of symbol and howto arrays wasn't checked in aout targets. PR 28403 * aout-ns32k.c (MY (reloc_howto)): Sanity check howto_table index. Make r_index unsigned. (MY_swap_std_reloc_in): Make r_index unsigned. * aoutx.h (MOVE_ADDRESS): Sanity check symbol r_index. (aout_link_input_section_std): Make r_index unsigned. (aout_link_input_section_ext): Likewise. * i386lynx.c (MOVE_ADDRESS): Sanity check symbol r_index. (swap_ext_reloc_in, swap_std_reloc_in): Make r_index unsigned. * pdp11.c (MOVE_ADDRESS): Sanity check symbol r_index. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28401] fail to allocate error in objdump at xmalloc.c:147
https://sourceware.org/bugzilla/show_bug.cgi?id=28401 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28402] fail to allocate error in objdump at objalloc.c:143
https://sourceware.org/bugzilla/show_bug.cgi?id=28402 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-06 Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28403] segv in objdump at disassemble_bytes (objdump.c:3055)
https://sourceware.org/bugzilla/show_bug.cgi?id=28403 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |2.38 --- Comment #2 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28419] global-buffer-overflow in objdump at objdump.c:3054
https://sourceware.org/bugzilla/show_bug.cgi?id=28419 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Alan Modra --- Fixed by the patch for pr28403 *** This bug has been marked as a duplicate of bug 28403 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28403] segv in objdump at disassemble_bytes (objdump.c:3055)
https://sourceware.org/bugzilla/show_bug.cgi?id=28403 --- Comment #3 from Alan Modra --- *** Bug 28419 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 binutils/28420] segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2021-10-06 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
