[Bug debug/101141] New: Fedora glibc debuginfo .dwz contains a partial unit with needed debuginfo but which is not imported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101141 Bug ID: 101141 Summary: Fedora glibc debuginfo .dwz contains a partial unit with needed debuginfo but which is not imported Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: roc at ocallahan dot org Target Milestone: --- The Fedora 34 package glibc-debuginfo-2.33-16.fc34.x86_64 package has glibc symbols in /usr/lib/debug/.build-id/08/1490fc18239fa63189a53e526a68ee5d19c571.debug whose .gnu_debugaltlink is /usr/lib/debug/usr/.dwz/glibc-2.33-16.fc34.x86_64. /usr/lib/debug/.build-id/08/1490fc18239fa63189a53e526a68ee5d19c571.debug has a compilation unit that imports the partial unit at 0x1f63c from the .dwz file: UNIT: < 0><0x000c GOFF=0x000795fa> DW_TAG_compile_unit DW_AT_producer <.debug_str(sup)+0x0001200e> DW_AT_language DW_LANG_C11 DW_AT_name global-locale.c DW_AT_comp_dir /usr/src/debug/glibc-2.33-16.fc34.x86_64/locale DW_AT_stmt_list <.debug_line+0xce8a> < 1><0x001e GOFF=0x0007960c>DW_TAG_imported_unit DW_AT_import <.debug_info(sup)+0x0001f63c> That partial unit contains a variable declaration whose DW_AT_specification (0x1f0d2) lives in another partial compilation unit: UNIT: < 0><0x000c GOFF=0x0001f63c> DW_TAG_partial_unit DW_AT_stmt_list <.debug_line+0x> ... < 1><0x0038 GOFF=0x0001f668>DW_TAG_variable DW_AT_specification <.debug_info+0x0001f0d2> DW_AT_decl_file 0x013b /usr/src/debug/glibc-2.33-16.fc34.x86_64/locale/global-locale.c DW_AT_decl_line 0x0040 DW_AT_decl_column 0x0013 DW_AT_location len 0x000a: 0e9b: DW_OP_const8u 0 DW_OP_form_tls_address UNIT: < 0><0x000c GOFF=0x0001f0cd> DW_TAG_partial_unit DW_AT_stmt_list <.debug_line+0x> < 1><0x0011 GOFF=0x0001f0d2>DW_TAG_variable DW_AT_name __libc_tsd_LOCALE DW_AT_decl_file 0x0089 /usr/src/debug/glibc-2.33-16.fc34.x86_64/locale/localeinfo.h DW_AT_decl_line 0x00e1 DW_AT_decl_column 0x0001 DW_AT_type <.debug_info+0x00035fb3> DW_AT_external yes DW_AT_declaration yes However, the partial unit at 0x1f0cd is not imported anywhere in /usr/lib/debug/.build-id/08/1490fc18239fa63189a53e526a68ee5d19c571.debug as far as I can tell. I think the compilation unit at global-locale.c, at least, should be importing it.
[Bug debug/101141] Fedora glibc debuginfo .dwz contains a partial unit with needed debuginfo but which is not imported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101141 roc at ocallahan dot org changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from roc at ocallahan dot org --- Good point. It looks correct in the generated .so so it's probably a DWZ bug. I'll repost it there. Sorry for the noise.
[Bug debug/101141] Fedora glibc debuginfo .dwz contains a partial unit with needed debuginfo but which is not imported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101141 --- Comment #3 from roc at ocallahan dot org --- Filed https://sourceware.org/bugzilla/show_bug.cgi?id=28000
[Bug debug/101431] New: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 Bug ID: 101431 Summary: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: roc at ocallahan dot org Target Milestone: --- For the "Line Number Program Header" "directories" field, the DWARF5 spec says "The first entry is the current directory of the compilation. Each additional path entry is either a full path name or is relative to the current directory of the compilation." In a simple testcase (see below) I get the following tables emitted (gcc 11.1.1): The Directory Table: 0 out 1 out 2 /usr/include The File Name Table Entry Dir TimeSizeName 0 0 0 0 file.c 1 1 0 0 file.c 2 1 0 0 message.h 3 2 0 0 stdio.h The compilation unit info from .debug_info is UNIT: dwo_id = 0x6ef97fe679da < 0><0x0014> DW_TAG_skeleton_unit DW_AT_low_pc0x00201728 DW_AT_high_pc 21 DW_AT_stmt_list <.debug_line+0x00bd> DW_AT_dwo_name out/main.dwo DW_AT_comp_dir /tmp/pernosco-submit-test DW_AT_GNU_pubnames yes DW_AT_addr_base <.debug_addr+0x0030> The correct path for 'file.c' is /tmp/pernosco-submit-test/out/file.c. Clearly, treating directory entry 1 as relative to directory entry 0 would give the wrong file path (something containing 'out/out'). It looks like gcc intends all directory entries to be treated as relative to the DW_AT_comp_dir from the .debug_info unit? Note that if the latter is true, then that violates the intent of the new behavior in DWARF5: > In DWARF Version 5, the current directory is explicitly present in the directories field. This is needed to support the common practice of stripping all but the line number sections ( .debug_line and .debug_line_str ) from an executable. To reproduce this bug: git clone --recurse-submodules https://github.com/Pernosco/pernosco-submit-test cd pernosco-submit-test ./build.sh dwarfdump -l out/main.debug
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 --- Comment #1 from roc at ocallahan dot org --- Clang follows the spec (clang 12, -fdebug-default-version=5): The Directory Table: 0 /tmp/pernosco-submit-test 1 out The File Name Table Entry Dir TimeSizeMD5 Name 0 0 0 0 F596F6F042BF2AD9E2B1C6B62633739A out/file.c 1 1 0 0 5E2CEC2A6335E978DEB5A35D865C41E2 message.h So I'm not sure what to do anymore when consuming DWARF5 line number information. I guess we could try "treat all relative directory entries as relative to the DW_AT_comp_dir" and hope that clang's directory entry 0 always matches DW_AT_comp_dir...
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 --- Comment #3 from roc at ocallahan dot org --- This is the Fedora 34 package. $ gcc --version gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3) $ rpm -qa|grep ^gcc-11 gcc-11.1.1-3.fc34.x86_64 $ rpm -qa|grep binutils-2 binutils-2.35.1-41.fc34.x86_64
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 roc at ocallahan dot org changed: What|Removed |Added CC||roc at ocallahan dot org --- Comment #9 from roc at ocallahan dot org --- It is a limitation of rr that we can't handle LL/SC, but it's not a bug we can just fix or work around. There is just no way to handle it in rr without hardware changes. Thus, if we can't find a way around this bug here, many Aarch64 users won't be able to use rr when they otherwise would have been able to. That would be unfortunate.
[Bug debug/102481] New: Incorrect source file path in debuginfo for assembly file specified with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102481 Bug ID: 102481 Summary: Incorrect source file path in debuginfo for assembly file specified with relative path Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: roc at ocallahan dot org Target Milestone: --- Steps to reproduce: $ cat > /tmp/test.S .global foo foo: ret $ cd /tmp/obj $ mkdir /tmp/obj $ gcc -g -c - o test.o ../test.S $ dwarfdump -i test.o I get UNIT: < 0><0x000c> DW_TAG_compile_unit DW_AT_stmt_list <.debug_line+0x> DW_AT_low_pc0x DW_AT_high_pc 1 DW_AT_name test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37.50 DW_AT_language DW_LANG_Mips_Assembler This indicates the source file is at /tmp/obj/test.S, which is incorrect. If I call the assembler directly, I get correct output: $ as -g -o test.o ../test.S $ dwarfdump -i test.o UNIT: < 0><0x000b> DW_TAG_compile_unit DW_AT_stmt_list <.debug_line+0x> DW_AT_low_pc0x DW_AT_high_pc 0x0001 DW_AT_name ../test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37.50 DW_AT_language DW_LANG_Mips_Assembler gcc version is 11.2.1 20210728 (Red Hat 11.2.1-1).
