[GHC] #3693: Show stack traces

[GHC]

#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