#3693: Show stack traces
---------------------------------+------------------------------------------
Reporter: jpet | Owner:
Type: feature request | Status: patch
Priority: normal | Milestone: 6.14.1
Component: Runtime System | Version: 6.10.4
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by batterseapower):
I had a look at how you might encode how to walk the STG stack using
DWARF. I don't think it's possible with DWARF v2 because the "register
rules" which define how the stack walking process updates registers as it
walks back up the stack do not include what we need.
Basically we need to update:
$eip to (top_closure->info->entry_code)
$ebp to (top_closure - size(top_closure))
(where the top_closure pointer can be determined from $eip and $ebp in a
standard way)
However, the DWARF2 register rules do not make provision for arbitrary
expressions: you can only transfer from other registers or a value stored
at some offset from the frame base address.
DWARFv3 adds expression and val_expression transfer rules which we could
easily use to implement this stack walking scheme. (Which have apparently
been implemented in GDB since 2006: http://cygwin.ru/ml/gdb-
patches/2006-03/msg00076.html).
The work that would need to be done is:
* Generate CFA and location information for code emitted from GHC
* Add libdwarf as a GHC dependency
* Augment the RTS with some code using libdwarf to reify the stack when
an exception occurs, passing it to Haskell land as in my existing patch
* The RTS code must be robust to missing DWARF info (i.e. if the
executable was stripped)
The benefit to this approach compared to the one my patch implements is
that dropping the debug info can be done with standard tools, and it will
be more pleasant to use GDB on GHC-generated executables.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3693#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
