Better DWARF info for Cmm procedures?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Better DWARF info for Cmm procedures?

Ömer Sinan Ağacan
Hi,

Currently debugging Cmm is a bit painful because we don't have enough debug
information to map assembly to Cmm lines, so I have do the mapping manually.
However I realized that when building .cmm files we actually generates some
debug information, in form of "ticks":

    //tick src<rts/Apply.cmm:631:9-37>
    _c2e::I64 = I64[R1 + 32];

Here the tick says that this assignment is for this Cmm line in Apply.cmm:

    Words = StgAP_STACK_size(ap);

I was wondering what needs to be done to generate DWARF information from those
so that gdb can show Cmm line we're executing, and gdb commands like `next`,
`break` etc. work.

I also realize that we don't consistently generate these ticks for all Cmm
lines, for example, in the same Cmm dump there isn't a tick before this line:

    (_c2j::I64) = call MO_Cmpxchg W64(R1, stg_AP_STACK_info,
stg_WHITEHOLE_info);

It's actually for Apply.cmm:646.

So there are two problems:

- Generate ticks for _all_ Cmm lines
- Generate DWARF information from those so that gdb can show current Cmm line,
  and commands like `next` and `break` work.

Anyone know how hard would this be to implement? I'm wondering if we could turn
this into a SoC project. It's a very well defined task, and given that we have
some DWARF support already, perhaps it's not too hard for a SoC.

Ömer
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Better DWARF info for Cmm procedures?

Ben Gamari-3
Ömer Sinan Ağacan <[hidden email]> writes:

> Hi,
>
> Currently debugging Cmm is a bit painful because we don't have enough debug
> information to map assembly to Cmm lines, so I have do the mapping manually.
> However I realized that when building .cmm files we actually generates some
> debug information, in form of "ticks":
>
>     //tick src<rts/Apply.cmm:631:9-37>
>     _c2e::I64 = I64[R1 + 32];
>
> Here the tick says that this assignment is for this Cmm line in Apply.cmm:
>
>     Words = StgAP_STACK_size(ap);
>
> I was wondering what needs to be done to generate DWARF information from those
> so that gdb can show Cmm line we're executing, and gdb commands like `next`,
> `break` etc. work.
>
The DWARF information that we produce are indeed derived from these
source notes. If you compile a C-- module with -g3 you will find the
resulting object file should have line number information.

> I also realize that we don't consistently generate these ticks for all Cmm
> lines, for example, in the same Cmm dump there isn't a tick before this line:
>
Indeed the C-- parser doesn't produce as many source notes
as you might find in C-- from the STG pipeline. Essentially it only adds
source notes on flow control constructs and assignments (see uses of
withSourceNote in CmmParse.y).

However, there is also a slightly more fundamental issue here: GHC's NCG
handles DWARF information with block granularity. Fixing this will be a
bit more involved. See compiler/nativeGen/Dwarf.hs for details.

One alternative would be to just finish debug information in the LLVM
backend and use this instead (originally D2343, although mpickering has
a newer version).

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Better DWARF info for Cmm procedures?

Ömer Sinan Ağacan
> However, there is also a slightly more fundamental issue here: GHC's NCG
> handles DWARF information with block granularity. Fixing this will be a
> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>
> One alternative would be to just finish debug information in the LLVM
> backend and use this instead (originally D2343, although mpickering has
> a newer version).

But LLVM backend also uses the same debug info we generate for NCG, no? So I
think debug info would still be in block granularity?

How hard do you think it would be to do the refactoring to generate debug info
for each Cmm source line, instead of each RawCmm block?

Ömer

Ben Gamari <[hidden email]>, 6 Oca 2019 Paz, 14:47 tarihinde şunu yazdı:

>
> Ömer Sinan Ağacan <[hidden email]> writes:
>
> > Hi,
> >
> > Currently debugging Cmm is a bit painful because we don't have enough debug
> > information to map assembly to Cmm lines, so I have do the mapping manually.
> > However I realized that when building .cmm files we actually generates some
> > debug information, in form of "ticks":
> >
> >     //tick src<rts/Apply.cmm:631:9-37>
> >     _c2e::I64 = I64[R1 + 32];
> >
> > Here the tick says that this assignment is for this Cmm line in Apply.cmm:
> >
> >     Words = StgAP_STACK_size(ap);
> >
> > I was wondering what needs to be done to generate DWARF information from those
> > so that gdb can show Cmm line we're executing, and gdb commands like `next`,
> > `break` etc. work.
> >
> The DWARF information that we produce are indeed derived from these
> source notes. If you compile a C-- module with -g3 you will find the
> resulting object file should have line number information.
>
> > I also realize that we don't consistently generate these ticks for all Cmm
> > lines, for example, in the same Cmm dump there isn't a tick before this line:
> >
> Indeed the C-- parser doesn't produce as many source notes
> as you might find in C-- from the STG pipeline. Essentially it only adds
> source notes on flow control constructs and assignments (see uses of
> withSourceNote in CmmParse.y).
>
> However, there is also a slightly more fundamental issue here: GHC's NCG
> handles DWARF information with block granularity. Fixing this will be a
> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>
> One alternative would be to just finish debug information in the LLVM
> backend and use this instead (originally D2343, although mpickering has
> a newer version).
>
> Cheers,
>
> - Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Better DWARF info for Cmm procedures?

Ben Gamari-3
Ömer Sinan Ağacan <[hidden email]> writes:

>> However, there is also a slightly more fundamental issue here: GHC's NCG
>> handles DWARF information with block granularity. Fixing this will be a
>> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>>
>> One alternative would be to just finish debug information in the LLVM
>> backend and use this instead (originally D2343, although mpickering has
>> a newer version).
>
> But LLVM backend also uses the same debug info we generate for NCG, no? So I
> think debug info would still be in block granularity?
>

> How hard do you think it would be to do the refactoring to generate debug info
> for each Cmm source line, instead of each RawCmm block?
>
I was under the impression that
the C-- AST can already capture debug information with arbitrarily fine
granularity. However, after looking again at the implementation it looks
like you raise a very good point: CmmTick nodes apparently cover the
entire block they reside within. This is indeed a problem.

I honestly don't know how hard it would be to fix this without serious
surgery to the C-- pipeline. It doesn't sound particularly easy.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment