Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#10236 closed bug (fixed)

DWARF unwind info is broken

Reported by: thoughtpolice Owned by:
Priority: high Milestone: 7.10.2
Component: Compiler (Debugging) Version: 7.10.1
Keywords: dwarf Cc: scpmw
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D792
Wiki Page:

Description

As reported by bitonic and petermw on #ghc (April 2nd):

07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using 
                 <https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide.  however, all I get is 
                 `Backtrace stopped: previous frame identical to this frame (corrupt stack?)`
07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if 
                 I'm not sure it's even necessary
07:04 < bitonic> are there any additional steps I should take?  or any way to make sure that the binary 
                 I'm generating is sane?

Change History (5)

comment:1 Changed 3 years ago by Austin Seipp <austin@…>

In 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5/ghc:

Restore unwind information generation

While we want to reduce the amount of information generated into
debug_info, it really doesn't make sense to remove block information
for unwinding.

This is a simple oversight introduced in 4ab57024, which severly
reduces the usefulness of generated unwind data. Thanks to bitonic
for spotting this!

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D792

GHC Trac Issues: #10236

comment:2 Changed 3 years ago by thoughtpolice

Status: newmerge

comment:3 Changed 3 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

comment:4 Changed 2 years ago by tibbe

Could we have a test for this so it doesn't break in the future?

comment:5 Changed 2 years ago by scpmw

See D792 - it's slightly tricky, because the only meaningful test would involve taking the produced object file apart. Best approach in my opinion would be to do some sanity checks on objdump/dwarfdump output. Still not exactly trivial to formulate a robust "all Haskell code covered" test though. Maybe calculate .text section size and compare it with the sum of ranges from .debug_info?

Side note: If/when we equip the RTS to consume DWARF this could become a lot more straightforward.

Last edited 2 years ago by scpmw (previous) (diff)
Note: See TracTickets for help on using tickets.