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?
