[LLVMdev] [RuntimeDyld] Section memory management

[Rafael Espíndola]

> 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?

For what it is worth, this is similar to  what "real" dynamic linkers
do. Running "strace ld-musl-x86_64.so.1 ./t" you will see something
like

open("./t", O_RDONLY)                   = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\343\2@\0\0\0\0\0"...,
960) = 960
mmap(0x400000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400000
mmap(0x401000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x401000

Note how the entire file is mmaped R+E and then the second segment is
switched to R+W, but it is known to be right next to the previous one.

Cheers,
Rafael