Better DWARF info for Cmm procedures?

Ben Gamari ben at
Sun Jan 6 11:47:55 UTC 2019

Ömer Sinan Ağacan <omeragacan at> 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).


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list