[Bug libbacktrace/108870] New: Gather file/line info for file/namespace/static variables

[Bug libbacktrace/108870] New: Gather file/line info for file/namespace/static variables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870

            Bug ID: 108870
           Summary: Gather file/line info for file/namespace/static
                    variables
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libbacktrace
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: ian at gcc dot gnu.org
  Target Milestone: ---

As discussed in PR108834, llvm symbolizer switched to providing detailed
file/line info from debuginfo rather than by the compiler emitting the location
data into sourcefiles.
Currently the libsanitizer libbacktrace based symbolizer for data uses
  backtrace_syminfo((backtrace_state *)state_, addr, SymbolizeDataCallback,
                    ErrorCallback, info);
which fills in (demangled) name from ELF symbol name, start and size (again,
from ELF).

We'd need to look up DWARF DW_TAG_variable DIEs (both at compile_unit/namespace
level and also nested in DW_TAG_subprogram and their children), which have
DW_AT_location of the form DW_OP_addr symbol_addr and map the symbol_addr to
DW_AT_decl_{file,line} and maybe DW_AT_name?

Wonder if we should just walk the whole .debug_info lazily the first time
something like libsanitizer asks for it, or if the current .debug_info walk
(read_function_info/read_function_entry) should gather it with other stuff if
libbacktrace user asks for it during library initialization somehow.  Though, I
think
read_function_info is invoked only if read_line_info was successful...

[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
             Blocks|                            |108834

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ian, any thoughts on this?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
[Bug 108834] LTO: ltrans temporary file is used as module name in ASAN

[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
Currently libbacktrace builds a mapping from compilation-unit PC ranges to line
programs.  This would be a completely different mapping, from variable
addresses to variable information.  As far as I know we would have to build it
from a complete scan of the .debug_info section.  Most programs don't need this
information, so it would be a shame to always build it.

Now I wish that there were some sort of options argument to
backtrace_create_state.  But actually backtrace_create_state does take a
threaded argument that almost everybody passes as 0.  The only non-zero cases I
could find in a web search were passing 1.  So we could redefine that as an
option.  Then programs that want variable information could pass 2 (or 3 for
variables plus threading).  With that option set, we can build a list of
address mapping to variables.

The next question would be whether we should unify the function and variable
mapping or keep them separate.  If we unify them we can use backtrace_pcinfo to
get variable information.  If we don't we should have another function that
does variable lookup.

It seems that the DWARF information does not include the size of the variable,
so to really get this right we'll have to also use the size information from
the symbol table, which is already available via backtrace_syminfo.

Any thoughts on whether the function/variable mappings should be unified or
distinct?

[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think even on the libsanitizer side we don't always need such non-automatic
variable debug info, e.g. if no diagnostics needs to be reported for global
vars but just for automatic ones, heap etc., so perhaps scanning the
.debug_info separately for it might be better for that purpose.