[LLVMdev] [MCJIT] Multiple GOT handling in RuntimeDyldELF

Keno Fischer kfischer at college.harvard.edu
Sun Jan 18 09:25:04 PST 2015


FWIW, I verified that we indeed crash with an assertion failure, if two
copies of

declare void @global_foo()

define internal void @foo() {
call void @global_foo()
ret void
}

are too far apart (with a definition of global_foo anywhere in the address
space).


On Sun, Jan 18, 2015 at 2:38 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> Hello everyone,
>
> As part of my quest to add TLS relocation support to MCJIT, I've been
> taking a closer look at the GOT implementation in RuntimeDyldELF and I
> believe that is not valid as currently implemented. In particular, I am
> wondering about the multiple GOT handling support introduced in r192020. If
> I understand correctly this can make code reuse the GOT table entry in a
> different object file. This doesn't seem correct to me as there is no
> guarantee that the loaded object files are allocated within 2GB of each
> other in memory. What was the intended use case of this feature?
> Additionally, it seems that currently every access through the GOT get it's
> own entry, when identical relocations could be combined into one entry. The
> GOTEntries array is also never cleared, causing memory and performance
> problems when loading multiple object files (this is a bug and easily
> fixed, but makes me think this feature isn't particularly well tested). I'm
> planning to redesign the GOT mechanism, but I would like to understand the
> use case intended in r192020 first, to make sure I don't design myself into
> a corner.
>
> Thanks,
> Keno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150118/db54ce49/attachment.html>


More information about the llvm-dev mailing list