<div dir="ltr">FWIW, I verified that we indeed crash with an assertion failure, if two copies of<div><br><div><div>declare void @global_foo()</div><div><br></div><div>define internal void @foo() {</div><div>call void @global_foo()</div><div>ret void</div><div>}</div></div></div><div><br></div><div>are too far apart (with a definition of global_foo anywhere in the address space).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 18, 2015 at 2:38 PM, Keno Fischer <span dir="ltr"><<a href="mailto:kfischer@college.harvard.edu" target="_blank">kfischer@college.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone,</div><div><br></div>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.<div><br></div><div>Thanks,</div><div>Keno</div></div>
</blockquote></div><br></div>