DWARF patches for 8.2

[Ben Gamari]

Hello fellow DWARF enthusiasts,

Tonight I finally made something of a breakthrough on the DWARF front;
after finding a small logic error in one of my patches I was able to get
a full stack trace into and out of Haskell using the runtime system's
native stack unwinder. This is quite exciting!

Recall that up until now there have been a few issues which can lead to
problems with unwinding,

 * #11353: Unsafe foreign calls can require the NCG to make stack
   pointer adjustments to accomodate native calling conventions. These
   adjustments need to be taken into account when we generate unwinding
   information.

 * #11337: Stack fixups produced by CmmStackLayout aren't reflected in
   unwinding information. Essentially this was a result of the fact that
   our current unwinding implementation assumes that stack layout is
   fixed over the course of a block.

 * #11338: The region surrounding safe foreign calls doesn't get proper
   unwinding information.

I've solved all three of these in my branch, which I've rebased, split
up, and posted to Phabricator. The result is quite a stack of
differentials,

 * D2740: OrdList: Add Foldable, Traversable instances

   Some throat-clearing.

 * D2735: Use newBlockId instead of newLabelC

   Just some refactoring.

 * D2737: NCGMonad: Add MonadUnique NatM instance

   This will come in handy later.

 * D2736: AsmCodeGen: Refactor worker in cmmNativeGens

   More refactoring I did while trying to understand the dataflow in the
   NCG.

 * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes

   This is a fix to what I believe is a bug which I noticed while
   reading through the implementation.

 * D2741: Generalize CmmUnwind and pass unwind information through NCG

   This is the bulk of the change. Here we refactor the treatment of
   unwinding information to provide the flexibility we will need to
   address the issues described above and fix #11353. Review is badly
   needed here.

 * D2742: CmmLayoutStack: Add unwind information on stack fixups

   Here we use the infrastructure provided in D2741 to fix #11337.

 * D2743: StgCmmForeign: Emit debug information for safe foreign calls

   Here we fix #11338 by adding unwind information to the safe foreign
   call prologue/epilogue code.

 * D2738: Cmm: Add support for undefined unwinding statements

   Fix unwinding information for stg_stack_underflow_frames, which we
   have no means of unwinding out of. For this we need to add support
   for unwinding declarations which tell the underwinder to "forget"
   about the value of a register.

Reviews would be greatly appreciated.

Cheers,

 - Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Ben Gamari]

CCing Luite who has done this sort of thing in the context of GHCJS.


Shea Levy  writes:

> Hi all,
>
> I'm interested in implementing a general solution for TH during
> cross-compilation, which if my naive lack-of-understanding is correct
> will broadly involve the following three tasks:
>
> 1. Make the generation of byte code, or at least the subset needed for
>useful TH use, target-independent

The bytecode machine itself (defined by ByteCodeInstr) is reasonably
target-independent. However, I suspect primops will be
problematic since they can appear in BCOs and are quite target dependent
(namely due to word size). I honestly don't know how much of a problem
this will be in practice; I tried loading a few example programs into
ghci -ddump-bcos and didn't see any PUSH_PRIMOP instructions, so perhaps
this won't be as problematic as I expect; it is worrisome though.

In general it's hard to identify "the subset needed for useful TH use"
but the fact that I can load the gitrev package (a fairly non-trivial
use of TH) into GHCi with no apparently platform dependent BCOs being
produced is promising.

> 2. Teach the external-interpreter to launch a build-native iserv when
>cross-compiling

For this you'll want to have a careful look through the Binary instances
for the things that are sent over the wire to iserv. You'll find these
occur in libraries/ghci/*.hs.

The first thing to look for is places where the system word-size may
leak into the serialized representation (e.g. instances where Ints and
Words are being used). Many of these can probably just be narrowed into
32-bit representations (e.g. in ResolvedBCO, where I think it's fair to
assume that four-billion bytecode instructions is an unreasonable BCO
size).

Don't forget to consider the platform dependence of the "primitive"
encodings like the Binary instance for ByteString [1]; you'll need to
take care to replace these with platform-independent encodings.

[1] 
https://hackage.haskell.org/package/binary-0.8.4.1/docs/src/Data.Binary.Class.html#line-611

> 3. Teach cabal to compile dependencies and modules for the build and
>target when cross-compiling and TH is used

You'll need to speak with the Cabal folks about this. However, it's
probably safe to ignore this for now; there's a lot of work to done
before you'll be in a position to start thinking about this.


> Of course, due to the generality of TH there will be code you can write
> that would be different in this approach from what you would get with a
> fully native compilation (e.g. due to GHC conditional compilation in the
> TH functions or FFI that does runtime host introspection), but since
> requiring a target device at build time is in many cases impractical (do
> you want to hook up an iPhone to your build farm?) and in some cases
> probably impossible (for targets without the resources to run a full GHC
> even if they can run GHC-compiled code) I think this is a reasonable
> restriction to require.
>
> My questions to the list are:
>
> * Is 1 above a pipe dream, keeping in mind that we are assuming the
>   availability of build-native versions of all dependencies and
>   already-compiled modules?

This sounds quite feasible to me.

> * Any pointers for getting started with 1?

See above. The first thing to do is to rid the Binary instances of
platform dependent encodings. This will be a bit of a game of
whack-a-mole, but it shouldn't be that hard.

Don't hesitate to ask if you get stuck!

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Paren removal in renamer

[Alan & Kim Zimmerman]

Hi all

I have been wrestling with something silly most of today.

T12530 has the following splice in it, which has parens around the "(Maybe
Int)".

$([d|   -- Test the Template Haskell pretty-printing for TypeApplications
f = id @(Maybe Int)
|])

the parsed source has these parens, but they are removed for the renamed
source.

I am modifying the pretty printer to be faithful to the original source, so
when the renamed source is printed it has no parens, causing T12530 to fail.

I have looked all over the source, and cannot see where the HsParTy is
removed.

Can anyone give me a pointer?

See details here [1]

My current work branch is here [2], but I am pretty sure there are no
changes affecting this there.

[1] http://lpaste.net/1624164315596587008
[2] https://github.com/alanz/ghc/tree/wip/T3384

Regards
  Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Making (useful subsets of) bytecode portable between targets

[Shea Levy]

Hi all,

I'm interested in implementing a general solution for TH during
cross-compilation, which if my naive lack-of-understanding is correct
will broadly involve the following three tasks:

1. Make the generation of byte code, or at least the subset needed for
   useful TH use, target-independent
2. Teach the external-interpreter to launch a build-native iserv when
   cross-compiling
3. Teach cabal to compile dependencies and modules for the build and
   target when cross-compiling and TH is used

Of course, due to the generality of TH there will be code you can write
that would be different in this approach from what you would get with a
fully native compilation (e.g. due to GHC conditional compilation in the
TH functions or FFI that does runtime host introspection), but since
requiring a target device at build time is in many cases impractical (do
you want to hook up an iPhone to your build farm?) and in some cases
probably impossible (for targets without the resources to run a full GHC
even if they can run GHC-compiled code) I think this is a reasonable
restriction to require.

My questions to the list are:

* Is 1 above a pipe dream, keeping in mind that we are assuming the
  availability of build-native versions of all dependencies and
  already-compiled modules?
* Any pointers for getting started with 1?
* Anything I'm missing?

Thanks,
Shea


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs