#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 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): Hi Tarrasch (1) Thanks - the good thing with using DWARF is that it doesn't really matter how you use it. My primary use case was actually to feed it to ThreadScope for profiling. Other people have talked about using Linux "perf" tools - this kind of openness is a good thing. From my point of view, going over the RTS will probably be the most fruitful approach most of the time, simply because it can account for more of the generated code's quirkiness (see the "IP-1" trouble with GDB). (2) The LLVM backend was actually what we started with, and at this point we still support line-number information. Walking the stack is more problematic - we can declare values as being visible in DWARF using `llvm.dbg.declare` and friends, but (as far as I know) have no way to communicate unwind rules to LLVM. Dwarf 4 isn't really the issue here though, Dwarf 3 is sufficient - even DW_CFA_def_cfa_expression will probably only be needed for rare variable- sized stack frames. (3) Tthere should actually be little magic involved with building my branch, as everything's on by default. Just make sure you have the dependencies (libdwarf). Also get the stack-trace branch of the "base" library from my GitHub, as otherwise you won't have a top-level exception handler that prints a stack trace. In case you run into any problems, just drop me a mail. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3693#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler