Re: Using dwfl to enumerate frames of current thread

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2015-08-19 at 14:11 +0200, Ben Gamari wrote:
> I am adding full DWARF unwinding-based backtrace support to the Glasgow
> Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information
> in the object files it produces [1] and we would like to be able to
> record full backtraces on both runtime system events and the user's
> request.

Nice. The [1] doesn't point anywhere though.

> The goal here is to expose a function to the runtime system and user
> programs allowing them to get a snapshot of the calling thread's current
> call-stack.

I don't want to push you away from using elfutils, but have you looked
at gcc's libbacktrace? That seems to be made precisely for your use case
(it is how gccgo provides call-stacks to the go runtime).
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libbacktrace;hb=HEAD

>  It seems that elfutils' current dwfl interfaces only allow
> for extraction of frames from Core dumps (with dwfl_core_file_attach)
> and ptrace'd processes (with dwfl_linux_proc_attach).
> 
> In principle, however, I can't see any reason why frames couldn't be
> extracted from the current thread. Besides taking care to preserve the
> registers at the out-set, it doesn't even seem that this should be 
> terribly difficult. Am I missing something? Does the interface for this
> exist and I have simply overlooked it? Does it not yet exist but is
> merely waiting for someone to implement it?

In general libdwfl functions are used mostly to introspect other
processes. But theoretically you could also use them on "self". It is
not a usecase that has come up yet though (or maybe people do and I just
didn't hear about it). I do think it should be possible and maybe it
already kind of works if you use dwfl_linux_proc_report and
dwfl_linux_proc_attach with pid () as argument. Although I wouldn't be
surprised if it would deadlock trying to ptrace itself.

So the best thing would be to write specific Dwfl_Thread_Callbacks
functions for "self". The only tricky part would be the
set_initial_registers callback. Which should be possible with some arch
specific assembler tricks.

Cheers,

Mark