[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