[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 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