Re: [PATCH v2 1/1] Don't rewind PC for GHC generated frames

[Simon Marchi <simon dot marchi at polymtl dot ca>]

Hi Bartosz,

Thanks for resending it, I am able to apply it now.  For those who
would like to play with the patch, there are good instructions on
the page Bartosz linked:

  https://ghc.haskell.org/trac/ghc/wiki/DWARF

The change seems good, but I'd like to understand the impact better.
Could you give examples of things that didn't work before and that
do work now?  It would be a good idea to add that to your commit log
too.

On 2018-02-01 06:06 PM, Bartosz Nitka wrote:
> GHC - the Haskell compiler generates code that violates one of
> GDB's assumptions.
> 
> GDB assumes that the address in a frame was generated by the call
> instruction and that it is the address of the call instruction
> plus 1 (I'm rephrasing the comment in get_frame_address_in_block).
> So to get the real address, one has to substract 1. This is doubly
> beneficial because some functions are "noreturn" and don't have
> further instructions after call, so GDB would be looking at gibberish.

To be more precise, the pc points to the instruction after the call which
is more than 1 byte after the address of the call (in the case of x86).
The pc returned by get_frame_address_in_block (pc - 1) isn't really a
valid PC, because it doesn't point at the beginning of an instruction.
But it's good enough because we are sure it's a value that falls within
the current block range.

Thanks,

Simon