This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using dwfl to enumerate frames of current thread


Mark Wielaard <mjw@redhat.com> writes:

> 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.
>
Doh.

This was supposed to point to Peter Wortmann's thesis [1]. As you might
imagine, generating useful line number information for a
lazily evaluated language without compromising optimization
opportunities is not a trivial task. Peter deserves quite some credit
for getting this working.

>> 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
>
This looks great although it's not immediately clear to me whether/how
it handles symbols from shared objects (which unfortunately GHC now
produces and links against by default).

>>  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.
>
Right, it looks like it will use ptrace and I can't imagine that going
well.

> 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.
>
I started down this road and am still pondering how to handle
set_initial_registers. It is definitely a rather delicate operation.
I'll give libbacktrace a shot and let you know if I end up returning to
libdw. I would be happy to contribute a patch upstream if I do end up
getting local backtraces working with libdw.

Thanks for your prompt feedback!

- Ben


[1] http://etheses.whiterose.ac.uk/8321/1/thesis.pdf

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]