Status and future of the LLVM backend

[Ben Gamari]

Joachim Breitner <mail at joachim-breitner.de> writes:

> [Resent, as ghc-dev does not like my other address. Sorry Ben]
>
> Hi,
>
>
> Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:
>> > thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
>> > First, because it picked llvm-3.5. After I tightened the dependencies to
>> > use llvm-3.4, it failed with 
>> >         dll-split: internal error: evacuate(static): strange closure
>> >         type 0
>> >             (GHC version 7.8.3.20141119 for arm_unknown_linux)
>> 
>> Indeed this looks like ld.bfd is being used.
>
> hmm, that’s annoying that --with-ld does not do the right thing. Is
> there a bug reported about this?
>
Not that I know of. It would be good if it did the right
thing although I'm afraid that the gold issue described below means that
it wouldn't make much difference in practice; I don't think we want to
be in the business of building in hacks working around linker quirks
into our build system.

>> > I then followed your advice from somewhere else and passed
>> > "--with-ld=ld.gold" to ./configure, but with the same effect:
>> 
>> Unfortunately I don't think this will be sufficient. I believe this
>> will only set the `LD` variable in the build system, which as far qas I
>> know is never used. We always call gcc to do our linking for us;
>> gcc will in turn just use whatever `ld` it finds in `PATH`. For this
>> reason I have resorted to simply adding a directory containing a symlink
>> to `ld.gold` to `PATH`. This is what this script[1] does.
>
> hmm, I’ll need to port that somehow to how the Debian package is built.
> But it seems to be cleaner to use the -B flag to gcc, available at least
> on Debian, according to
> https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.
>
> What would be a reliable way to make the build system pass
> -B/usr/bin/ld.gold to gcc? Is
> SRC_HC_OPTS     += -optc-B/usr/bin/ld.gold
> in mk/build.mk a good idea?
>
Indeed this is much cleaner. I just wanted a way to accomplish this
without editing build.mk.

>> Unfortunately it's also a bit more subtle than this; it's very likely
>> that the ghc you are bootstrapping from contains relocations that aren't
>> supported by gold. For this reason you'll likely need to build some of
>> the utilities with `ld.bfd` the continue the build with `ld.gold`. The
>> above script implements this fairly reliably.
>
> What would be the symptoms of that problem?
>
You'll see an error message of the form,

    /usr/bin/ld.gold: error: /usr/lib/ghc/libHSrts.a(GetTime.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
    
I'm tempted to just try implementing this relocation type but sadly
these sorts of patches always take longer to get right than I expect.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/a4a74f44/attachment.sig>