[PATCH v2] libstdc++: Improve ostream output for std::stacktrace

[Jonathan Wakely]

I've removed gcc-patches from the CC list.

On Fri, 17 Oct 2025 at 09:34, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > On Fri, 17 Oct 2025 at 08:06, Florian Weimer wrote:
> >>
> >> * Jonathan Wakely:
> >>
> >> > With this change locations that don't have a source file look like this:
> >> >
> >> >   18# __libc_start_call_main at [0x7fd6568f6574]
> >> >   19# __libc_start_main@GLIBC_2.2.5 at [0x7fd6568f6627]
> >> >   20# _start at [0x4006a4]
> >>
> >> Note that DSO name plus offset would be significantly more useful than
> >> just the address, due to ASLR.
> >
> > I think that's the topic of
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196 (although the
> > report seems to switch topic halfway through).
> >
> > I don't know how to get that info from libbacktrace, but the bug above
> > suggests using dladdr1 for it (I think dladdr would work too, and is
> > more portable).
>
> Using _dl_find_object would be faster, but getting the real base address
> from the link map returned is currently non-trivial.  (Currently, dladdr
> does not use _dl_find_object, and getting the symbol name is quite
> ineffiecient, too.)  See the documentation of l_addr in the glibc
> manual.


I don't think the performance of dumping a std::stacktrace to an
ostream is too critical.

Boost.Stacktrace has a "safe dump" function which just serializes the
addresses, with no processing or formatting. That seems much better if
performance matters, and then decode those addresses later, but
Boost.Stacktrace also supports constructing a frame (what we call
std::stacktrace_entry in the standard) from an address, which isn't
supported by std::stacktrace_entry.