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] |
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] |