[Bug libstdc++/122232] New: Consider caching symbol info in std::stacktrace_entry

[redi at gcc dot gnu.org]

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

            Bug ID: 122232
           Summary: Consider caching symbol info in std::stacktrace_entry
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Keywords: ABI
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
            Blocks: 106749
  Target Milestone: ---

The query members of std::stacktrace_entry all do the same work:

    // [stacktrace.entry.query], query
    [[nodiscard]]
    string
    description() const
    {
      string __s;
      _M_get_info(&__s, nullptr, nullptr);
      return __s;
    }

    [[nodiscard]]
    string
    source_file() const
    {
      string __s;
      _M_get_info(nullptr, &__s, nullptr);
      return __s;
    }

    [[nodiscard]]
    uint_least32_t
    source_line() const
    {
      int __line = 0;
      _M_get_info(nullptr, nullptr, &__line);
      return __line;
    }

This calls _Info::_M_populate which calls backtrace_pcinfo.

If user code does something like:

    return std::tuple{e.description(), e.source_file(), e.source_line()};

then it will result in three calls to backtrace_pcinfo.

Doing `std::cout << e` only results in a single call to _M_get_info, retrieving
all three values at once, but there's no API for users to do that.

We could consider storing a member of type _Info in the std::stacktrace_entry
and populating it lazily on the first call to one of the query functions.

The downsides of this are that sizeof(std::stacktrace_entry) would grow
considerably. Currently it only stores a single uintptr_t, which makes the
memory consumption for a std::stacktrace very efficient. Caching the info would
add two std::strings and uint_least32_t (and a bool flag indicating whether the
_Info was populated yet). It would also mean allocating memory for both
std::string members even if the user only wants one of them.

Another option would be to add a new member function that queries the three
values at once. Maybe we should propose that for the standard.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
[Bug 106749] Implement C++23 library features