#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 blitzcode): Thank you for your kind words! I've been most interested in the lower-level faults simply because they have the least support from the existing tools. I'm currently back on another project after spending a week or so on the debugging project, but I'm thinking about how to turn it into a a more usable and portable tool. Basically, I think I would rewrite it to be based fully on gdb's machine interface or lldb's C++ API. This buys me a few things: - Unified code to access the target process state (no more Win32 ReadProcessMemory() vs Linux ptrace() vs OS X mach_vm_read_overwrite()) - Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos) - Support for both stack traces from live processes and core dumps with no extra work - C/C++/etc. stack unwinding already done The biggest issue still seems to be keeping the debugger's view of the stack and heap in sync with the runtime / compiler sources. GHC's RTS data structures / memory layout seem fairly stable from what I can tell, but I'd like to make everything as automatic as possible. After all, there are quite a few different OS, CPU architecture, compiler and RTS flavors to support. I would use the DerivedConstants.h header and generate some additional offsets, register mappings and such using a similar mechanism. I still think the approach of directly accessing the target process through OS-level functions has some merit. 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. The CCS is a fairly good tool for pinning down the location of a crash, but Peter's work on improving DWARF information is really what I'm looking forward to for profiling. Hopefully this can be a part of 7.10! Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)? Also, do you think it would be feasible to support frame pointers as an option for GHC? I know debuggers have long moved on to doing stack unwinding with debug information, but there seem to be numerous profiling tools still using them for speed and simplicity. There's been some discussion here regarding RTS APIs to access the stack, but are there any ideas on how to expose this API to other processes? There are advantages to having debugging, profiling and heap walking tools be as unobtrusive as possible, not changing the program code or runtime behavior. RTS support for this type of access could make writing such tools simpler. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3693#comment:55 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler