Re: SFrame stack tracer

[Florian Weimer <fweimer@redhat.com>]

* Claudiu Zissulescu-Ianculescu:

> Looking to dwarf stack unwinding support in glibc, it looks to me like
> it is based on unwinder routines from libgcc.

Correct.  We have an old copy of the unwinder in the glibc sources, but
most architectures do not use it.

> Now, I would like to clarify if you would like to see the entire SFrame
> stack tracer implementation added to glibc source code, i.e., without
> any libgcc callbacks like in dwarf case.

I think this makes sense.  The SFrame data is generated by binutils from
DWARF, so if we'd call a library, I suppose it would have to be
something provided by binutils.  (Although technically, the DWARF data
that ends up in PT_GNU_EH_FRAME has been significantly rewritten by
binutils, too.)

Having the implementation in glibc proper also makes it easier to figure
out how to discover signal frames because glibc controls the SA_RESTORER
handshake on the userspace side.  An unwinder separate from glibc would
not have access to these internal glibc implementation details today.

> As far as I can see, a SFrame stack tracer implementation will need some
> architecture specific code added too, which may imply some extra
> interfaces to be created on top of the suggested one in dl_find_object
> structure.

Yes, that's not going to be enough, but I think some form is required
for getting SFrame data quickly.

Thanks,
Florian