Debug data extraction (NCG support)
authorPeter Wortmann <scpmw@leeds.ac.uk>
Fri, 28 Nov 2014 23:07:48 +0000 (00:07 +0100)
committerAustin Seipp <austin@well-typed.com>
Tue, 16 Dec 2014 21:02:39 +0000 (15:02 -0600)
commitf46aa7338cd0318e8cd7b3a760dd6024576e0fbb
treec7676e8eb55a4abd880312938609d1c8b424ee32
parent711a51adcf8b32801289478443549947eedd49a2
Debug data extraction (NCG support)

The purpose of the Debug module is to collect all required information
to generate debug information (DWARF etc.) in the back-ends. Our main
data structure is the "debug block", which carries all information we have
about a block of code that is going to get produced.

Notes:

* Debug blocks are arranged into a tree according to tick scopes. This
  makes it easier to reason about inheritance rules. Note however that
  tick scopes are not guaranteed to form a tree, which requires us to
  "copy" ticks to not lose them.

* This is also where we decide what source location we regard as
  representing a code block the "best". The heuristic is basically that
  we want the most specific source reference that comes from the same file
  we are currently compiling. This seems to be the most useful choice in
  my experience.

* We are careful to not be too lazy so we don't end up breaking streaming.
  Debug data will be kept alive until the end of codegen, after all.

* We change native assembler dumps to happen right away for every Cmm group.
  This simplifies the code somewhat and is consistent with how pretty much
  all of GHC handles dumps with respect to streamed code.

(From Phabricator D169)
compiler/cmm/Debug.hs [new file with mode: 0644]
compiler/ghc.cabal.in
compiler/main/CodeOutput.hs
compiler/main/DynFlags.hs
compiler/nativeGen/AsmCodeGen.hs