ELF shared libraries - motivation for the PLT

Question

Could self-modifying code be used to speed up function calling in dynamically linked libraries?

As far as I understand it, ELF shared libraries use a kind of indirect jump table (the procedure linkage table, or PLT) to enable lazy binding of library functions. The purpose seems to be to avoid having to modify the table in the code segment while still enabling lazy resolution of function positions at the first call.

Wouldn't it be faster to dynamically create the code for that table at load time, or possibly even at the first function call?

Is it to enable sharing of the code segment between processes as much as possible (a dynamic table would be private to a process)? Is it for security reasons (writable code shouldn't be executable - but JITs do that all the time, and the write permission could be added and removed by the loader before actually starting the program)?

Or is it a combination of those, and the small performance gain per function call just wouldn't be worth the effort?

Answer 1

I suppose we're talking about x86 architecture.

You cannot have Self-Modifying Code in protected mode, which is used by most UNIX-based operating systems (and not only) that I'm aware of, because the code segments are always read-only. A loader does not control that -it is something that is being handled by the memory management subsystem of the kernel.

But even if you could "create the code for that table at load time" as you say, it would defy the whole purpose of shared libraries. This way, each process would have a "private" copy of the library's functions in its address space, effectively increasing its memory footprint -one of the reasons that shared libraries were created, was to address this issue.

The whole process you that you describe is quite complex, and it would cost more processing cycles than the PLT method that is used nowadays, and probably would introduce more, new & interesting security issues.

Answer 2

ELF DSOs may use a flag (DF_TEXREL) to announce that they require rellocations by modification of their text section (which is normally read-only). The jump table approach along with PIE position independent code should be more optimal, though.

(Found that in http://www.akkadia.org/drepper/dsohowto.pdf, but other resources mention this too).