[Bug binutils/28679] New: readelf -l /usr/bin/npc segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=28679 Bug ID: 28679 Summary: readelf -l /usr/bin/npc segfault Product: binutils Version: 2.38 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Fedora 35, I got $ /export/build/gnu/tools-build/binutils-gitlab/build-x86_64-linux/binutils/readelf -l /usr/bin/npc Elf file type is DYN (Position-Independent Executable file) Entry point 0x2a5c0 There are 14 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align PHDR 0x0040 0x0040 0x0040 0x0310 0x0310 R 0x8 INTERP 0x0350 0x0350 0x0350 0x001c 0x001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x 0x 0x 0x0001a4d0 0x0001a4d0 R 0x1000 LOAD 0x0001b000 0x0001b000 0x0001b000 0x001a34ed 0x001a34ed R E0x1000 LOAD 0x001bf000 0x001bf000 0x001bf000 0x00069f48 0x00069f48 R 0x1000 LOAD 0x00229810 0x0022a810 0x0022a810 0xf868 0xfab8 RW 0x1000 DYNAMIC0x002373a8 0x002383a8 0x002383a8 0x0230 0x0230 RW 0x8 NOTE 0x0370 0x0370 0x0370 0x0020 0x0020 R 0x8 NOTE 0x0390 0x0390 0x0390 0x0044 0x0044 R 0x4 TLS0x00229810 0x0022a810 0x0022a810 0x0005 0x00f8 R 0x10 GNU_PROPERTY 0x0370 0x0370 0x0370 0x0020 0x0020 R 0x8 GNU_EH_FRAME 0x001ecf4c 0x001ecf4c 0x001ecf4c 0x6fdc 0x6fdc R 0x4 GNU_STACK 0x 0x 0x 0x 0x RW 0x10 GNU_RELRO 0x00229810 0x0022a810 0x0022a810 0xf7f0 0xf7f0 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 03 .init .plt .text .fini 04 .rodata .debug_gdb_scripts .eh_frame_hdr .eh_frame .gcc_except_table 05 .tdata .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 06 .dynamic 07 .note.gnu.property 08 .note.gnu.build-id .note.ABI-tag 09 .tdata .tbss 10 .note.gnu.property 11 .eh_frame_hdr 12 13 .tdata .init_array .fini_array .data.rel.ro .dynamic .got Segmentation fault (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28682] New: GCC can no longer catch EH on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=28682
Bug ID: 28682
Summary: GCC can no longer catch EH on windows
Product: binutils
Version: 2.38 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: euloanty at live dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103657
#include
int main()
try
{
throw 0;
}
catch(...)
{
puts("Hello EH\n");
return 1;
}
GCC cannot catch EH on windows anymore.
while clang with -fuse-ld=lld and g++ -m32 all work
D:\hg\fast_io\tests\0017.error>g++ -o error error.cc -Ofast -std=c++2b -s
-march=native -I../../include -lntdll -fuse-ld=lld
D:\hg\fast_io\tests\0017.error>error
errc:no_such_file_or_directory
clang++ -o error error.cc -Ofast -std=c++2b -s -march=native -I../../include
-lntdll
D:\hg\fast_io\tests\0017.error>error
Looks like it is GNU ld linker's issue. Need to report there probably.
while switch linker to lld it works. It looks like an issue in the ld linker I
think.
Cannot catch EH is serious tbh. Please fix it asap.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28682] GCC can no longer catch EH on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=28682 cqwrteur changed: What|Removed |Added Host||x86_64-w64-mingw32 Target||x86_64-w64-mingw32 Priority|P2 |P1 Build||x86_64-linux-gnu CC||euloanty at live dot com Severity|normal |critical -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28679] readelf -l /usr/bin/npc segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=28679 --- Comment #1 from H.J. Lu --- (gdb) bt #0 load_separate_debug_info ( main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo", xlink=xlink@entry=0x4e5180 , parse_func=parse_func@entry=0x431550 , check_func=check_func@entry=0x432ae0 , func_data=func_data@entry=0x7fffdb60, file=file@entry=0x51d430) at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057 #1 0x0043328d in check_for_and_load_links (file=0x51d430, filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381 #2 0x004332ae in check_for_and_load_links (file=0x51b070, filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #3 0x004332ae in check_for_and_load_links (file=0x519970, filename=0x518b80 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #4 0x004332ae in check_for_and_load_links (file=0x514c70, filename=0x514c00 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #5 0x004332ae in check_for_and_load_links (file=0x510a40, filename=0x50a7c0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #6 0x004332ae in check_for_and_load_links (file=0x5106e0, filename=0x50aa80 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #7 0x004332ae in check_for_and_load_links (file=0x50b610, filename=0x509180 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #8 0x004332ae in check_for_and_load_links (file=0x50b2b0, filename=0x7fffe45c "/usr/bin/npc") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11390 #9 0x0045169b in load_separate_debug_files (file=file@entry=0x50b2b0, filename=0x7fffe45c "/usr/bin/npc") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11497 #10 0x0042c587 in process_object (filedata=) at /export/gnu/import/git/sources/binutils-gdb/binutils/readelf.c:21963 #11 process_object (filedata=0x50b2b0) at /export/gnu/import/git/sources/binutils-gdb/binutils/readelf.c:21885 #12 0x004034ba in process_file ( --Type for more, q to quit, c to continue without paging-- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28679] readelf -l /usr/bin/npc segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=28679 --- Comment #2 from H.J. Lu --- The bug is triggered by ./binutils/readelf -x .gnu_debuglink /export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo Hex dump of section '.gnu_debuglink': 0x 6e70632d 312e312e 312d312e 6665 npc-1.1.1-1.fc35 0x0010 2e783836 5f36342e 64656275 6700 .x86_64.debug... 0x0020 fe9ca375...u -- You are receiving this mail because: You are on the CC list for the bug.
Re: nm/objdump --hep still display unsupported styles about --demangle.
On Wed, Nov 10, 2021 at 05:02:01PM +0800, nora-pxh wrote: > Hello, I find a problem about usage. > The commit 1910070b298052d7ca8e4024891465824588c1e9 fixed demangle.h to > remove support for ancient GNU (pre-3.0), Lucid, ARM, HP, and EDG demangling > styles. > But usage of nm and objdump is still show the following message. > -C, --demangle[=STYLE] Decode low-level symbol names into user-level names > The STYLE, if specified, can be `auto' (the > default), > `gnu', `lucid', `arm', `hp', `edg', `gnu-v3', `java' > or `gnat' > So if you execute --demangle=gnu, it will display error message: unknown > demangling style gnu. > Would you delete unsupported styles from usage of nm and objdump? This was fixed with commit 0d64622696e02 nm now shows -C, --demangle[=STYLE] Decode mangled/processed symbol names STYLE can be "none", "auto", "gnu-v3", "java", "gnat", "dlang", "rust" -- Alan Modra Australia Development Lab, IBM
[Bug gas/28610] ASAN error: in riscv_update_subset bfd/elfxx-riscv.c:2245
https://sourceware.org/bugzilla/show_bug.cgi?id=28610 Nelson Chu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nelson Chu --- Thanks Martin, Marked as resolved and fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28672] Link failure on some targets when building as PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=28672 --- Comment #1 from Alan Modra --- Since you are building -static the executable may be pulling in most of libc.a and thus be quite large. A relocation overflow is very likely the correct result from the linker. You might need to explore gcc options for compiling in larger code models. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28679] readelf -l /usr/bin/npc segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=28679 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=40eb8b92a1c795cda00bf931ab9cdd74da434d54 commit 40eb8b92a1c795cda00bf931ab9cdd74da434d54 Author: H.J. Lu Date: Fri Dec 10 13:34:22 2021 -0800 Don't return the main file as the separate debug info On Fedora 35, $ readelf -d /usr/bin/npc caused readelf to run out of stack since load_separate_debug_info returned the input main file as the separate debug info: (gdb) bt #0 load_separate_debug_info ( main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo", xlink=xlink@entry=0x4e5180 , parse_func=parse_func@entry=0x431550 , check_func=check_func@entry=0x432ae0 , func_data=func_data@entry=0x7fffdb60, file=file@entry=0x51d430) at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057 #1 0x0043328d in check_for_and_load_links (file=0x51d430, filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381 #2 0x004332ae in check_for_and_load_links (file=0x51b070, filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") Return NULL if the separate debug info is the same as the input main file to avoid infinite recursion. PR binutils/28679 * dwarf.c (load_separate_debug_info): Don't return the input main file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28679] readelf -l /usr/bin/npc segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=28679 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.38 --- Comment #4 from H.J. Lu --- Fixed for 2.38. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28684] New: [RISCV] 32-bit --enable-targets=all build breakage issue
https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Bug ID: 28684 Summary: [RISCV] 32-bit --enable-targets=all build breakage issue Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nelsonc1225 at sourceware dot org Target Milestone: --- The 32-bit build failed again when --enable-targets=all, the original discussion was here, https://sourceware.org/pipermail/binutils/2021-November/118485.html For now, the dis-assembler (objdump) need to call the riscv architecture parser from bfd/elfxx-riscv.c (https://sourceware.org/pipermail/binutils/2021-November/118444.html), but this will break the 32-bit host --enable-targets=all build when building the libopcodes.a, [Copied from Alan's comments] usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `riscv_disassemble_insn': /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:541: undefined reference to `riscv_multi_subset_supports' /usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `riscv_get_disassembler': /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:892: undefined reference to `riscv_release_subset_list' /usr/local/bin/ld: /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:893: undefined reference to `riscv_parse_subset' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:940: objdump] Error 1 As I known, there are two solutions could fix the problem, The first one was suggested by Alan Modra, and the idea is great - don't compile some opcodes files when bfd is 32-bit only, https://sourceware.org/pipermail/binutils/2021-November/118500.html https://sourceware.org/pipermail/binutils/2021-December/118751.html But seems like this caused the simulator and gdb build failed, when building bfd in 32-bit mode. Therefore, Andrew Bugress have a proposed solution to make gdb can build as usual, https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html At the meantime, Jim Wilson also remind us that my previous RFC patch may works, and then we probably won't need the extra gdb fixes, and the idea of solution was also came from him, https://sourceware.org/pipermail/binutils/2021-November/118498.html I'm OK that we can commit Andrew's gdb patch first, and then probably spend some times to make sure if my RFC patch do works. If so, then we can revert the gdb patch at that time. I collect all the information here, in case I forgot the details when coming back to see this issue again, or someone is interested and try to resolve it. Thanks Nelson -- You are receiving this mail because: You are on the CC list for the bug.
