<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 10, 2017 at 12:41 PM, kyra <span dir="ltr"><<a href="mailto:kyrab@mail.ru" target="_blank">kyrab@mail.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/10/2017 9:00 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure if I understand correctly. If my understanding is correct, you are saying that GHC can link either .o or .so at runtime, which sounds a bit odd because .o is not designed for dynamic linking. Am I missing something?<br>
</blockquote></span>
Yes, GHC runtime linker *does* link .o files not only doing all necessary relocations but also creating trampolines for "far" code to fulfill "small" memory model.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also do not understand why only static libraries need "compile/link pass" -- they at least don't need a compile pass, as they contain compiled .o files, and they indeed need a link pass, but that's also true for a single big .o file generated by -r, no? After all, in order to link against a .a file, I think you need to pull out a .o file from a .a and do whatever you need to do to link a single big .o file.<br>
</blockquote></span>
Don't quite understand this.<br>
The idea is that when creating a package you should *at the very least* provide a static library a client can statically link against. You optionally may create a shared library for a client to link against, but to do so you should *recompile* the whole package because things differ now (this is how GHC works), – you can't simply link all your existing object code (what you've produced the static library from) into this shared library. But if you want to provide the single prelinked *.o file (for GHC runtime linker consumption) you need no to perform any extra compile step, you simply link all your object files (exactly those which went to the package's static library) into this *.o file with 'ld -r'.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IIUC, GHC is faster when handling .a files compared to a prelinked big .o file, even if they contain the same binary code/data. But it sounds like an artifact of the current implementation of GHC, because, in theory, there's no reason the former is much inefficient than the latter. If that's the case, doesn't it make more sense to improve GHC?<br>
</blockquote></span>
No. GHC **runtime** linker is much slower when handling *.a files (and this is exactly the culprit of this whole story) since it goes through the whole archive and links each object module separately doing all resolutions and relocations and trampolines, than when linking already prelinked big *.o file.<br></blockquote><div><br></div><div>Looks like I still do not understand why a .a can be much slower than a prelinked .o. As far as I understand, "ld -r" doesn't reduce amount of data that much. It doesn't reduce the number of relocations, as relocations in input object files are basically passed through to the output. It doesn't reduce the number of symbols that much, as the combined object file contains a union of all symbols appeared in the input files. So, I think the amount of data in a .a is essentially the same as a prelinked .o. I wonder what can make a difference in speed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are, perhaps, some confusions related to what GHC *runtime* linker is. GHC runtime linker goes out into the scene when either GHC is used interactively, or GHC encounters the code which it has to execute at compile time (Template Haskell/quasiquotations). Thus GHC compiler must link some external code during it's own run time.<br>
<br>
HTH.<br>
<br>
Cheers,<br>
Kyra<br>
<br>
</blockquote></div><br></div></div>