Interface loading and dynamic linking

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ben Gamari

In trying to test my LLVM-dynamic linking changes, I've encountered some
builds which fail with,

    Bad interface file: dist-install/build/GHC/CString.hi
        mismatched interface file ways (wanted "dyn", got "")

during `make install`. The failing command is `ghc-stage2`, invoked by
`ghc-cabal`,

    ../../inplace/bin/ghc-stage2 '-B/opt/exp/ghc/root-ghc-7.8-dyn/lib/ghc-7.7.20131221' '--abi-hash' '-fbuilding-cabal-package' '-O' '-outputdir' 'dist-install/build' '-odir' 'dist-install/build' '-hidir' 'dist-install/build' '-stubdir' 'dist-install/build' '-i' '-idist-install/build' '-i.' '-idist-install/build/autogen' '-Idist-install/build/autogen' '-Idist-install/build' '-optP-include' '-optPdist-install/build/autogen/cabal_macros.h' '-package-name' 'ghc-prim-0.3.1.0' '-hide-all-packages' '-no-user-package-db' '-package-id' 'builtin_rts' '-XHaskell2010' 'GHC.CString' 'GHC.Classes' 'GHC.Debug' 'GHC.IntWord64' 'GHC.Magic' 'GHC.PrimopWrappers' 'GHC.Tuple' 'GHC.Types' 'GHC.Prim' '-package-name' 'ghc-prim'

The build is on an x86_64 box with `build.mk` containing,

    GhcDebugged = YES
    DYNAMIC_BY_DEFAULT = YES

    # Roughly BuildFlavour=quick-llvm without disabling dynamic linking
    SRC_HC_OPTS        = -H64m -O0 -fllvm # -keep-llvm-files
    GhcStage1HcOpts    = -O -fllvm
    GhcStage2HcOpts    = -O0 -fllvm
    GhcLibHcOpts       = -O -fllvm
    SplitObjs          = NO
    HADDOCK_DOCS       = NO
    BUILD_DOCBOOK_HTML = NO
    BUILD_DOCBOOK_PS   = NO
    BUILD_DOCBOOK_PDF  = NO

   
I've spent the morning tracing through the interface loading code and
have finally met an impasse. As far as I can tell, the relevant
subset of the call graph is,

    LoadIface.lhs: loadInterface
      LoadIface.lhs : findAndReadIface
        Finder.hs: findExactModule
          Finder.hs: findHomeModule
            Finder.hs: homeSearchCache
              Finder.hs: findHomeModule
   
        findAndReadIface(read_file)
        findAndReadIface(checkBuildDynamicToo)
          whenGeneratingDynamicToo
            TcRnMonad.hs: withDoDynamicToo
              DynFlags.hs: dynamicTooMkDynamicDynFlags
                findAndReadIface(read_file)
   
        where
          findAndReadIFace(read_file)
            LoadIface.lhs : readIface
              BinIface.hs : readBinIface

Up until `checkBuildDynamicToo` the dynflags have,

    ways dflags     == [WayDyn]
    buildTag dflags == "dyn"
    hiSuf dflags    == "hi"
    dynHiSuf dflags == "dyn_hi"

Given this, it's perhaps unsurprising that `readBinIface` gets quite
confused when it attempts to read `dist-install/build/GHC/CString.hi` to
find that it was compiled with a null tag, not `dyn` as expected.
If I add `-static` to the command line the build succeeds. However,
adding `-dynamic` or `-dynamic-too` or omitting all of the above (due to
`DYNAMIC_BY_DEFAULT`) all fail.

It seems that `findAndReadIface` attempts to account for
`-dynamic-too` but I don't see how the approach should work:
it tries to first load the static interface file (but with
`ways==[WayDyn]`) then tries again to load the interface using
`DynFlags` and .hi file name constructed for the dynamic case. I can't
see how this would ever work as `readBinIface` will expect to see a
dynamic interface file due to the DynFlags' ways.

It's also unclear how the `-dynamic` case (not `-dynamic-too`) is handled under this
scheme. I would have thought that running with `-dynamic` would cause
`hiSuf == dynHiSuf` but I can't find any code to suggest this is the case.

Could someone offer some insight into how interface loading, `-dynamic`,
and `-dynamic-too` are supposed to interact?

Thanks,

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

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ian Lynagh
On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote:
>
>     DYNAMIC_BY_DEFAULT = YES

Dynamic-by-default was a previous experiment to get GHCi to use the
system linker. We now use dynamic-too instead.

I'm not sure whether dynamic-by-default works, and in any case it's
probably not something we want to keep supporting. I'd recommend
removing it.


Thanks
Ian


Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ben Gamari
Ian Lynagh <igloo at earth.li> writes:

> On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote:
>>
>>     DYNAMIC_BY_DEFAULT = YES
>
> Dynamic-by-default was a previous experiment to get GHCi to use the
> system linker. We now use dynamic-too instead.
>
Causing GHCi to use the system linker is indeed my intent. Given the
currently rather broken state of the ARM runtime linker it seems like
the easiest way to get ARM supported as somewhat-first-class citizen is
to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to
accomplish this.

I've now reproduced the error on both my x86_64 laptop and my ARM
box. It seems that the only effect of `DYNAMIC_BY_DEFAULT` is to set the
default ways. Even with `-dynamic` or `-dynamic-too` set explicitly the
error persists so I don't believe that the option itself is the issue.

Cheers,

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

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ian Lynagh
On Sun, Dec 22, 2013 at 06:56:11PM -0500, Ben Gamari wrote:

> Ian Lynagh <igloo at earth.li> writes:
>
> > On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote:
> >>
> >>     DYNAMIC_BY_DEFAULT = YES
> >
> > Dynamic-by-default was a previous experiment to get GHCi to use the
> > system linker. We now use dynamic-too instead.
> >
> Causing GHCi to use the system linker is indeed my intent. Given the
> currently rather broken state of the ARM runtime linker it seems like
> the easiest way to get ARM supported as somewhat-first-class citizen is
> to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to
> accomplish this.

You shouldn't need dynamic-by-default. It should Just Work in HEAD, both
unregisterised and registerised.


Thanks
Ian


Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ben Gamari
Ian Lynagh <igloo at earth.li> writes:

> You shouldn't need dynamic-by-default. It should Just Work in HEAD, both
> unregisterised and registerised.
>
Just to clarify, how does one configure GHCi to use dynamic linking now?
Should I interpret your message to mean that it is already configured
this way? Where in the tree is this configured?

To be perfectly clear, I want to ensure that dynamic linking is always
preferred over linking static objects with the RTS linker. Will this
happen as things stand? How does GHCi decide how to load a library? Is
this the role of GhcDynamic?

I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the
problems I'm observing. It seems to me that it is functionally equivalent
to passing the `-dynamic` flag as they both simply add `WayDyn` to DynFlag's
`ways` list. Do you have any idea where they might differ?

Cheers,

- Ben

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

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Carter Schonwald
I think part of what Ian is saying is that the default config for a Perf
build for HEAD will build the dylib versions of all the libraries. Or am I
not understanding the question?

eg: see the default make file
https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75


On Mon, Dec 23, 2013 at 12:59 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> Ian Lynagh <igloo at earth.li> writes:
>
> > You shouldn't need dynamic-by-default. It should Just Work in HEAD, both
> > unregisterised and registerised.
> >
> Just to clarify, how does one configure GHCi to use dynamic linking now?
> Should I interpret your message to mean that it is already configured
> this way? Where in the tree is this configured?
>
> To be perfectly clear, I want to ensure that dynamic linking is always
> preferred over linking static objects with the RTS linker. Will this
> happen as things stand? How does GHCi decide how to load a library? Is
> this the role of GhcDynamic?
>
> I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the
> problems I'm observing. It seems to me that it is functionally equivalent
> to passing the `-dynamic` flag as they both simply add `WayDyn` to
> DynFlag's
> `ways` list. Do you have any idea where they might differ?
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131223/5cc7a7c0/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ben Gamari
Carter Schonwald <carter.schonwald at gmail.com> writes:

> I think part of what Ian is saying is that the default config for a Perf
> build for HEAD will build the dylib versions of all the libraries. Or am I
> not understanding the question?
>
> eg: see the default make file
> https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75
>
Yes, I understand this. That being said, it will also build static
versions. On ARM these static libraries should be avoided as the RTS's
linker is still quite broken. Therefore I'd like to ensure that dynamic
linking is used whenever possible.

Cheers,

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

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Carter Schonwald
why would the RTS linker be used? I'm not understanding that piece. I
thought static linking and dynamic linking both use the system linkers now.
 Are you meaning the rts linker use for ghci in <= 7.6?


On Mon, Dec 23, 2013 at 1:08 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > I think part of what Ian is saying is that the default config for a Perf
> > build for HEAD will build the dylib versions of all the libraries. Or am
> I
> > not understanding the question?
> >
> > eg: see the default make file
> > https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75
> >
> Yes, I understand this. That being said, it will also build static
> versions. On ARM these static libraries should be avoided as the RTS's
> linker is still quite broken. Therefore I'd like to ensure that dynamic
> linking is used whenever possible.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131223/badfd907/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Ben Gamari
Carter Schonwald <carter.schonwald at gmail.com> writes:

> why would the RTS linker be used? I'm not understanding that piece. I
> thought static linking and dynamic linking both use the system linkers now.
>  Are you meaning the rts linker use for ghci in <= 7.6?
>
As far as I know, the RTS linker is always used in the static case. The
system dynamic linker is just that, a dynamic linker for linking dynamic
objects. This could just be a misconception I somehow formed, but that
is my understanding.

Cheers,

- Ben

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

Reply | Threaded
Open this post in threaded view
|

Interface loading and dynamic linking

Simon Marlow-7
In reply to this post by Ben Gamari
On 23/12/13 17:59, Ben Gamari wrote:
> Ian Lynagh <igloo at earth.li> writes:
>
>> You shouldn't need dynamic-by-default. It should Just Work in HEAD, both
>> unregisterised and registerised.
>>
> Just to clarify, how does one configure GHCi to use dynamic linking now?

You set DYNAMIC_GHC_PROGRAMS=YES (which is the default on supported
platforms).

This causes GHC itself to be built with -dynamic, which in turn causes
GHCi to look for and to load the dynamic versions of packages.

Cheers,
        Simon


> Should I interpret your message to mean that it is already configured
> this way? Where in the tree is this configured?
>
> To be perfectly clear, I want to ensure that dynamic linking is always
> preferred over linking static objects with the RTS linker. Will this
> happen as things stand? How does GHCi decide how to load a library? Is
> this the role of GhcDynamic?
>
> I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the
> problems I'm observing. It seems to me that it is functionally equivalent
> to passing the `-dynamic` flag as they both simply add `WayDyn` to DynFlag's
> `ways` list. Do you have any idea where they might differ?
>
> Cheers,
>
> - Ben
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>