... | ... | @@ -147,7 +147,7 @@ Usually you want to do something along these lines: |
|
|
|
|
|
|
|
|
Symbols in GHC are encoded using something called the Z-encoding (see
|
|
|
[ Encoding.hs](http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs)). Basically special symbols are replaced by sequences
|
|
|
[compiler/utils/Encoding.hs](/trac/ghc/browser/ghc/compiler/utils/Encoding.hs)). Basically special symbols are replaced by sequences
|
|
|
beginning with `z` or `Z`. eg. `state#` becomes
|
|
|
`statezh`. The letter `z` itself is replaced by `zz`.
|
|
|
|
... | ... | @@ -171,7 +171,7 @@ symbol relates to, and *kind* is the kind of symbol: |
|
|
</th></tr></table>
|
|
|
|
|
|
|
|
|
(see [ CLabel.hs](http://darcs.haskell.org/ghc/compiler/cmm/CLabel.hs)
|
|
|
(see [compiler/cmm/CLabel.hs](/trac/ghc/browser/ghc/compiler/cmm/CLabel.hs)
|
|
|
for a table of these). Note that if you're matching up assembly with
|
|
|
C-- and (info) tables next to code is enabled (as it is by default),
|
|
|
then code that is named `entry` is equivalent to `info` symbols
|
... | ... | @@ -204,7 +204,7 @@ looking at heap & stack objects in a running program. |
|
|
|
|
|
|
|
|
You can display memory in gdb with something like `x/4a` to
|
|
|
display 4 words of memory, or using our [gdb macros](/trac/ghc/attachment/wiki/Debugging/CompiledCode/.gdbinit)[](/trac/ghc/raw-attachment/wiki/Debugging/CompiledCode/.gdbinit) you get slighty
|
|
|
display 4 words of memory, or using our [gdb macros](/trac/ghc/attachment/wiki/Debugging/CompiledCode/.gdbinit)[](/trac/ghc/raw-attachment/wiki/Debugging/CompiledCode/.gdbinit) you get slightly
|
|
|
nicer output:
|
|
|
|
|
|
```wiki
|
... | ... | @@ -219,7 +219,7 @@ nicer output: |
|
|
the bottom. In this case I'm displaying memory pointed to by the
|
|
|
register `rbx`, which corresponds to the STG register `R1` on
|
|
|
a recent x86_64 build. Check
|
|
|
[ MachRegs.h](http://darcs.haskell.org/ghc/includes/stg/MachRegs.h) to
|
|
|
[includes/stg/MachRegs.h](/trac/ghc/browser/ghc/includes/stg/MachRegs.h) to
|
|
|
see which machine registers correspond to which STG registers on your
|
|
|
platform.
|
|
|
|
... | ... | @@ -229,7 +229,7 @@ closure for the `Int` value 5. Closures always consist of an info |
|
|
pointer (`GHCziBase_Izh_con_info` in this case, the `I#`
|
|
|
constructor), followed by any number of payload words (just one word
|
|
|
containing the value 5, here). Full details on closure layouts are in
|
|
|
[ Closures.h](http://darcs.haskell.org/ghc/includes/rts/storage/Closures.h).
|
|
|
[includes/rts/storage/Closures.h](/trac/ghc/browser/ghc/includes/rts/storage/Closures.h).
|
|
|
|
|
|
|
|
|
It looks like the next word contains garbage, probably because it is
|
... | ... | @@ -254,7 +254,7 @@ execution. The *info pointer* of a closure actually points to the |
|
|
entry code (this is a trick used by GHC so that the common operation
|
|
|
of jumping to the entry code for a closure can be done with a single
|
|
|
indirection). The layout of info tables is defined in
|
|
|
[ InfoTables.h](http://darcs.haskell.org/ghc/includes/rts/storage/InfoTables.h).
|
|
|
[includes/rts/storage/InfoTables.h](/trac/ghc/browser/ghc/includes/rts/storage/InfoTables.h).
|
|
|
|
|
|
|
|
|
To display the stack, you need to know what the `Sp` register is
|
... | ... | @@ -304,7 +304,7 @@ $5 = {srt_offset = 4241688, __pad_srt_offset = 6684481, i = {layout = { |
|
|
|
|
|
The `type` field tells us what kind of object this is, in this
|
|
|
case `36`}, which means a `RET_SMALL` stack frame (see
|
|
|
[ ClosureTypes.h](http://darcs.haskell.org/ghc/includes/rts/storage/ClosureTypes.h)
|
|
|
[includes/rts/storage/ClosureTypes.h](/trac/ghc/browser/ghc/includes/rts/storage/ClosureTypes.h)
|
|
|
for a list of closure types, but make sure you are
|
|
|
looking at the right version of this file for the build you're using,
|
|
|
because the types do change).
|
... | ... | @@ -348,7 +348,7 @@ See `-ddump-stg, -ddump-simpl, -ddump-cmm, -dppr-debug`. |
|
|
To figure out which bit of Haskell code corresponds to the assembly
|
|
|
fragment you're looking at, you need to look at the STG intermediate
|
|
|
code generated by GHC. Use the `-ddump-stg` flag. The reason we
|
|
|
have to look at the STG is becase this is the last phase before code
|
|
|
have to look at the STG is because this is the last phase before code
|
|
|
generation, after all the transformations have happened, and the
|
|
|
symbol names in STG correspond pretty directly to the symbols you see
|
|
|
in the object code.
|
... | ... | |