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] |
Ben Gamari <ben@smart-cactus.org> writes: > 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 turns out that libbacktrace only uses DWARF line information, not the .debug_frames unwinding information. This means that we would have needed to implement our own unwinder for the Haskell stack (separate From the C stack). Unfortunately libbacktrace doesn't provide the necessary tools to make this feasible. I also ended up looking at libunwind, which seems to have similar goals to libbacktrace and also suffers from the same insufficient interfaces. So, I've come back to libdw. At this point I have basic stacktrace output for the C stack using libdw's unwinder. My set_initial_registers implementation can be found here [1]. It seems to work reasonably well although I would appreciate a second pair of eyes to ensure I didn't miss something. Moreover, I have also implemented unwinding of the Haskell evaluation stack (the stack used by Haskell code). While the unwinding and symbol lookup work, I'm not getting any line information out of libdw. I'm quite certain that my object (namely a statically linked executable) has proper line information as addr2line can extract meaningful positions for the addresses found in my stacktraces. My stacktrace implementation is quite simple [2] and I suspect I'm merely missing something obvious. Can anyone spot what I've missed? Thanks, - Ben [1] https://github.com/ghc/ghc/compare/142a673...bgamari:libdw#diff-c6aeaf799bec63621050f2515ca3ba9eR207 [2] https://github.com/ghc/ghc/compare/142a673...bgamari:libdw#diff-c6aeaf799bec63621050f2515ca3ba9eR241
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] |