[LLVMdev] [RuntimeDyld] Section memory management

Keno Fischer kfischer at college.harvard.edu
Wed Mar 18 19:48:43 PDT 2015


Hi Lang,

I'm in the process of completing my patch to add TLS support to
RuntimeDyld. The one remaining issue I have is that the memory manager
sometimes allocates the .got section too far away from the code section, so
I'd like to get some input on the possible options.

1. Don't allocate a separate GOT section, but use the Stub mechanism
instead. I had considered this, but I believe, we currently set RW
permission on the GOT section, so we can't really put that in the code
section without making it RWX, which has the obvious security problems. I
suspect in most cases a RO GOT is fine, but I'm not sure what the consensus
is here.

2. Change the memory manager to guarantee that the got section is closer.
This seems better to me, but is also not quite easy. Currently the memory
manager tries very hard to put pages of one permission type closer
together, but doesn't really care at all about where e.g. code and data
sections are placed relative to each other. This seems slightly backwards
to me as I imagine you would the code/data/got sections of an object file
to be close together if possible, while the objects files can be farther
from each other (with the appropriate code model of course). Can you think
of a good reason why the other way would be better? The other problem is
that the GOT section size isn't known until all the relocations are
processed. The stub mechanism has a similar problem, which we deal with by
just assuming all relocations require a stub when reserving memory. I
suspect I could just do the same for the GOT. However, since we need to
walk all the relocations anyway, wouldn't it be better to add a method to
each RuntimeDyld implementation that counts exactly how much Stub/GOT space
it would need?

Let me know what you think.
Thanks,
Keno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150318/2146bc7b/attachment.html>


More information about the llvm-dev mailing list