[v3,0/1] Don't rewind PC for GHC generated frames

Message ID 20180204000647.19188-1-niteria@gmail.com
Headers show
Series
  • Don't rewind PC for GHC generated frames
Related show

Message

Bartosz Nitka Feb. 4, 2018, 12:06 a.m.
Hi Simon and everyone else,

Thank you Simon for taking a look at my patch.
The only thing that changed between v2 and v3 is the 
commit log.

The main improvement is an example that shows the impact
of this change. The example is fairly small, on bigger ones the
effect is bigger. I've been using GDB for debugging Haskell 
code and often you have to resort to manually unwinding the 
stack, which can be time consuming and isn't friendly to beginners.

I've also corrected the claim that substracting 1 would 
somehow land us at the beginning of the call instruction
and reworded a couple of sentences to make it read better.

As a side note, Haskell code can be pretty dense and a lot
of functionality can fit on one line. GHC already puts column
numbers in the debugging information, but from what I can tell
GDB doesn't expose that in any way. 
Would that be a worthwhile addition to GDB?

Thanks,
Bartosz

Bartosz Nitka (1):
  Don't rewind PC for GHC generated frames

 gdb/ChangeLog    | 7 +++++++
 gdb/dwarf2read.c | 4 ++++
 gdb/frame.c      | 9 ++++++++-
 gdb/symtab.h     | 3 +++
 4 files changed, 22 insertions(+), 1 deletion(-)

-- 
2.14.1

Comments

Yao Qi Feb. 12, 2018, 1:50 p.m. | #1
On Sun, Feb 4, 2018 at 12:06 AM, Bartosz Nitka <niteria@gmail.com> wrote:
> As a side note, Haskell code can be pretty dense and a lot

> of functionality can fit on one line. GHC already puts column

> numbers in the debugging information, but from what I can tell

> GDB doesn't expose that in any way.

> Would that be a worthwhile addition to GDB?


If what you meant is DW_LNS_set_column, then, other compilers
also generates it, and GDB doesn't use it.  Maybe, GDB can use
it in TUI mode, to blink on the right line and column, or GDB tells
MI front ends the column number so they can highlight accordingly.
What do you want to add to GDB?

-- 
Yao (齐尧)
Bartosz Nitka Feb. 12, 2018, 2:14 p.m. | #2
2018-02-12 13:50 GMT+00:00 Yao Qi <qiyaoltc@gmail.com>:

> If what you meant is DW_LNS_set_column, then, other compilers

> also generates it, and GDB doesn't use it.


I'm not familiar with DW_LNS_set_column, perhaps GHC can be made to use it.
The current encoding is described in [1]. Based on my experimentation [2] lldb
seems to understand it. Note
    LineEntry: [0x00000000004056f7-0x0000000000405720):
/data/users/bnitka/tmp/fib.hs:3:9
there. The second number (9) is the column number.

> Maybe, GDB can use

> it in TUI mode, to blink on the right line and column, or GDB tells

> MI front ends the column number so they can highlight accordingly.


I'm not a regular user of TUI mode or other front ends, so this
wouldn't be the priority for me.

> What do you want to add to GDB?


Using the example from the summary. Currently gdb shows:

   (gdb) bt
   #0  Main_zdwfib_info () at fib.hs:3
   #1  Main_zdwfib_info () at fib.hs:4
   #2  Main_zdwfib_info () at fib.hs:4
   #3  Main_zdwfib_info () at fib.hs:4

I'd like it to show something like:

   (gdb) bt
   #0  Main_zdwfib_info () at fib.hs:3:9
   #1  Main_zdwfib_info () at fib.hs:4:20
   #2  Main_zdwfib_info () at fib.hs:4:20
   #3  Main_zdwfib_info () at fib.hs:4:20

Similarly, currently when you do:

  (gdb) info line *f1_info
  Line 4 of "fib.hs" starts at address...

I'd like to get:

  Line 4, column 20 of "fib.hs" starts at address...

The ability to break on line + column would also be welcome, but it's
not that important to me.

[1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debug-info.html?highlight=dw_tag_ghc_src_note#dw-tag-ghc-src-note
[2] https://ghc.haskell.org/trac/ghc/wiki/DWARF#lldb
Yao Qi Feb. 12, 2018, 2:42 p.m. | #3
On Mon, Feb 12, 2018 at 2:14 PM, Bartosz Nitka <niteria@gmail.com> wrote:
> 2018-02-12 13:50 GMT+00:00 Yao Qi <qiyaoltc@gmail.com>:

>

>> If what you meant is DW_LNS_set_column, then, other compilers

>> also generates it, and GDB doesn't use it.

>

> I'm not familiar with DW_LNS_set_column, perhaps GHC can be made to use it.

> The current encoding is described in [1]. Based on my experimentation [2] lldb

> seems to understand it. Note

>     LineEntry: [0x00000000004056f7-0x0000000000405720):

> /data/users/bnitka/tmp/fib.hs:3:9

> there. The second number (9) is the column number.


GHC is completely new to me, so I don't understand the reason
DW_TAG_ghc_src_note was added to describe line/column.  To me,
it is .debug_line's responsibility.

>

>> What do you want to add to GDB?

>

> Using the example from the summary. Currently gdb shows:

>

>    (gdb) bt

>    #0  Main_zdwfib_info () at fib.hs:3

>    #1  Main_zdwfib_info () at fib.hs:4

>    #2  Main_zdwfib_info () at fib.hs:4

>    #3  Main_zdwfib_info () at fib.hs:4

>

> I'd like it to show something like:

>

>    (gdb) bt

>    #0  Main_zdwfib_info () at fib.hs:3:9

>    #1  Main_zdwfib_info () at fib.hs:4:20

>    #2  Main_zdwfib_info () at fib.hs:4:20

>    #3  Main_zdwfib_info () at fib.hs:4:20

>

> Similarly, currently when you do:

>

>   (gdb) info line *f1_info

>   Line 4 of "fib.hs" starts at address...

>

> I'd like to get:

>

>   Line 4, column 20 of "fib.hs" starts at address...

>


Yes, they are good improvements to GDB, IMO.

FAOD, it is good to me that we can show and use column
information in GDB.  If the column information is from
DW_LNS_set_column, that is absolutely fine to me, because
DW_LNS_set_column is in standard dwarf spec.  However,
if column information is from DW_TAG_ghc_src_note, we want
to support it, it should be discussed as "Haskell/GHC support in
GDB".  It is great if you can describe the reason that
DW_TAG_ghc_src_note was invented rather than using existing
dwarf line program to describe line/column information.

-- 
Yao (齐尧)
Bartosz Nitka Feb. 19, 2018, 1:27 p.m. | #4
Hi Yao,

Thanks for taking a look.
I agree that GHC should use DW_LNS_set_column and I will try to see
what I can do about that.
My understanding is that DW_TAG_ghc_src_note was introduced because we
don't get enough
fidelity with DW_LNS_set_column. I think it's because we have ranges
for expression locations, and
sometimes the start points overlap, but I'm a bit hazy on the details.
I want to try DW_LNS_set_column and see how far I get with that.

One thing I don't understand is why lldb seems to understand
DW_TAG_ghc_src_note. I need to investigate a bit more.

Thanks,
Bartosz