public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* SFrame stack tracer
@ 2024-10-09 17:09 Claudiu Zissulescu-Ianculescu
  2024-10-24 10:59 ` Florian Weimer
  0 siblings, 1 reply; 2+ messages in thread
From: Claudiu Zissulescu-Ianculescu @ 2024-10-09 17:09 UTC (permalink / raw)
  To: Florian Weimer; +Cc: toolchain-patches_ww_grp, libc-alpha

Hi Florian,

I am comming back to you for clarifying some aspects of SFrame stack
tracer support in glibc.
Looking to dwarf stack unwinding support in glibc, it looks to me like
it is based on unwinder routines from libgcc.
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.
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.

Looking forward for your reaction, and thank you,
Claudiu

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: SFrame stack tracer
  2024-10-09 17:09 SFrame stack tracer Claudiu Zissulescu-Ianculescu
@ 2024-10-24 10:59 ` Florian Weimer
  0 siblings, 0 replies; 2+ messages in thread
From: Florian Weimer @ 2024-10-24 10:59 UTC (permalink / raw)
  To: Claudiu Zissulescu-Ianculescu; +Cc: toolchain-patches_ww_grp, libc-alpha

* 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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-10-24 10:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-09 17:09 SFrame stack tracer Claudiu Zissulescu-Ianculescu
2024-10-24 10:59 ` Florian Weimer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).