#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw):

Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos)

As far as the current design goes, we already read out the symbol and DWARF tables of all loaded executable sections. So by going through the RTS you'd have that part covered as well (well, at least for Linux). See [https://github.com/scpmw/ghc/blob/profiling-ncg/rts/Dwarf.c Dwarf.c].

Mostly for profiling, where we'd like to inspect the program hundreds or even thousands of times per second with as little overhead as possible.

I suppose you are talking about an external sampling routine that walks the stack in certain intervals? My approach would have been to try to do that in the RTS, but this might work as well.

Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)?

I saw it work at least once - and when in doubt, the machinery for generating DWARF unwind from Cmm is flexible enough that there is probably a way to make it work if it doesn't already. Going from Haskell back to C is probably trickier. Bottom line is that even with with the points you mention, I am still a fan of the "leave it to the RTS"-approach. My main reason is that we already have (and need) quite a bit of functionality in the RTS, so having an external program re-implement stack walking and symbol lookup seems awkward to me. So maybe the solution here is to make the RTS more powerful. Could it be a possibility to use the mentioned libraries to displace libdwarf in the RTS? It's already a somewhat uncommon dependency, so if the switch would buy us unwinding of the C stack and better portability, it might work out quite nicely. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3693#comment:56 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler