public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0
@ 2023-12-04 12:21 gprocida at google dot com
  2023-12-04 12:41 ` [Bug libdw/31111] " mark at klomp dot org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: gprocida at google dot com @ 2023-12-04 12:21 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

            Bug ID: 31111
           Summary: Handle Clang DWARF 5 DW_AT_decl_file 0
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libdw
          Assignee: unassigned at sourceware dot org
          Reporter: gprocida at google dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

There is an ambiguity in DWARF 5 noted and resolved for DWARF 6 in
https://dwarfstd.org/issues/210713.1.html.

Clang's treatment of this in DWARF 5 is as if it were DWARF 6, rather than
following the letter of the standard (and having to create and use an extra
file entry). See: https://github.com/llvm/llvm-project/issues/74097

Incidentally, following that change, the only sensible way to represent "no
source file" (for builtins like __va_list) is perhaps by omitting the attribute
altogether. (Clang and GCC treat __va_list and its members rather
inconsistently.)

For the record here, clang -gdwarf-5 populates the file table index 0 as per
DWARF 5, section 6.2.4 *and uses it in declarations*. However, elfutils
dwarf_decl_file detects index 0 specially and does not examine the file table
entry, reporting, "no file".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libdw/31111] Handle Clang DWARF 5 DW_AT_decl_file 0
  2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
@ 2023-12-04 12:41 ` mark at klomp dot org
  2023-12-04 12:47 ` gprocida at google dot com
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2023-12-04 12:41 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
So I assume this means dwarf_decl_file doesn't work for such DWARF because it
has:

  /* Zero means no source file information available.  */
  if (idx == 0)
    {
      __libdw_seterrno (DWARF_E_NO_ENTRY);
      return NULL;
    }

Are there other issues?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libdw/31111] Handle Clang DWARF 5 DW_AT_decl_file 0
  2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
  2023-12-04 12:41 ` [Bug libdw/31111] " mark at klomp dot org
@ 2023-12-04 12:47 ` gprocida at google dot com
  2024-01-20 21:01 ` mark at klomp dot org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: gprocida at google dot com @ 2023-12-04 12:47 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

--- Comment #2 from gprocida at google dot com ---
I investigated and opened these other DWARF 4/5 issues with DW_AT_decl_file.

* https://github.com/llvm/llvm-project/issues/73652
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112726

Please let me know if you think they are at related to this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libdw/31111] Handle Clang DWARF 5 DW_AT_decl_file 0
  2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
  2023-12-04 12:41 ` [Bug libdw/31111] " mark at klomp dot org
  2023-12-04 12:47 ` gprocida at google dot com
@ 2024-01-20 21:01 ` mark at klomp dot org
  2024-01-24  9:06 ` gprocida at google dot com
  2024-02-13  1:45 ` amerey at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2024-01-20 21:01 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-01-20

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to gprocida from comment #2)
> I investigated and opened these other DWARF 4/5 issues with DW_AT_decl_file.
> 
> * https://github.com/llvm/llvm-project/issues/73652
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112726
> 
> Please let me know if you think they are at related to this issue.

Sorry, I am confused by those bug reports. Those look like a bugs in
llvm-dwarfdump.

Lets keep this bug for the issue where DW_AT_decl_file has the value zero, with
DWARFv5. In that case we might want to change dwarf_decl_file from reporting
NULL (an error, no source file) to reporting the value of index 0 in the file
table (if that exists).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libdw/31111] Handle Clang DWARF 5 DW_AT_decl_file 0
  2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
                   ` (2 preceding siblings ...)
  2024-01-20 21:01 ` mark at klomp dot org
@ 2024-01-24  9:06 ` gprocida at google dot com
  2024-02-13  1:45 ` amerey at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: gprocida at google dot com @ 2024-01-24  9:06 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

--- Comment #4 from gprocida at google dot com ---
The llvm-dwarfdump issues were an unfortunate red herring as I thought I had
found more problems with compilers.

Your comment 1 is exactly what I found. I'm not aware of anything further at
this stage. The LLVM developers did not seem inclined to follow GCC's approach
to the  DWARF 5 standard as written.

I think the workaround suggested in comment 3 makes sense. It makes to check
the behaviour of the various versions of GCC that support DWARF 5 against this,
particularly in regard to __va_list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libdw/31111] Handle Clang DWARF 5 DW_AT_decl_file 0
  2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
                   ` (3 preceding siblings ...)
  2024-01-24  9:06 ` gprocida at google dot com
@ 2024-02-13  1:45 ` amerey at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: amerey at redhat dot com @ 2024-02-13  1:45 UTC (permalink / raw)
  To: elfutils-devel

https://sourceware.org/bugzilla/show_bug.cgi?id=31111

Aaron Merey <amerey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amerey at redhat dot com
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Aaron Merey <amerey at redhat dot com> ---
Fixed in the following commit:

commit add63e0317b6e27dd4077b19e998e6c56a3becb5
Author: Aaron Merey <amerey@redhat.com>
Date:   Fri Feb 9 21:10:19 2024 -0500

    Handle DW_AT_decl_file 0

    Modify dwarf_decl_file to support DW_AT_decl_file with value 0.

    Because of inconsistencies in the DWARF 5 spec, it is ambiguous whether
    DW_AT_decl_file value 0 is a valid .debug_line file table index for the
    main source file or if it means that there is no source file specified.

    dwarf_decl_file interprets DW_AT_decl_file 0 as meaning no source file
    is specified.  This works with DWARF 5 produced by gcc, which duplicates
    the main source file name at index 0 and 1 of the file table and avoids
    using DW_AT_decl_file 0.

    However clang uses DW_AT_decl_file 0 for the main source index with no
    duplication at another index.  In this case dwarf_decl_file will be
    unable to find the file name of the main file.

    This patch changes dwarf_decl_file to treat DW_AT_decl_file 0 as a normal
    index into the file table, allowing it to work with DWARF 5 debuginfo
    produced by clang.

    As for earlier DWARF versions which exclusively use DW_AT_decl_file 0
    to indicate that no source file is specified, dwarf_decl_file will now
    return the name "???" if called on a DIE with DW_AT_decl_file 0.

    https://sourceware.org/bugzilla/show_bug.cgi?id=31111

    Signed-off-by: Aaron Merey <amerey@redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-02-13  1:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-04 12:21 [Bug libdw/31111] New: Handle Clang DWARF 5 DW_AT_decl_file 0 gprocida at google dot com
2023-12-04 12:41 ` [Bug libdw/31111] " mark at klomp dot org
2023-12-04 12:47 ` gprocida at google dot com
2024-01-20 21:01 ` mark at klomp dot org
2024-01-24  9:06 ` gprocida at google dot com
2024-02-13  1:45 ` amerey at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).