Hacker News Reader

Comment by ioquatix | Hacker News Reader

Static linking avoids this overhead right?

Yes, a statically-linked binary will have all internal references resolved by the linker. If PIE is disabled, the addresses will all be fixed, which makes exploiting such a binary much easier. Glibc has only just added support for static PIE executables (in Feb of this year), and I'm not sure what the implementation is - whether it relocates all the references in the binary (increased memory usage), or uses a PLT/GOT approach to support relocations (increased runtime overhead).

Depending on the linkage, function calls internal to the library can use ordinary PC-relative function calls instead of fully indirect function calls. So you get the low per-call cost, but pay a higher per-process cost in memory consumption.

Exactly.

The cost of indirect jumps isn't implied by position independent (PIE/PIC) code alone, but by PIE/PIC combined with jumps across separately loadable segments. For jumps _within_ a segment you can just use a direct relative call which is the fastest type of call and doesn't require any load-time fixup ever.

Of course then there is also the consideration of symbol interposition: if you want to support that even _within_ a statically linked thing (usually something other than the main executable), then you need a GOT-like thing, but not necessarily a PLT-like thing.

Does it necessarily use more memory though? Eg. code is usually read-only hence can be shared by multiple processes (for apps that create many invocations of the same executable).

You'd have to check every page to see if you already have a read-only copy in memory though, right?

Not quite, necessarily. It means another program can't share the same DLL as that one. So you might well end up using more memory that way.

But you can use LTO with more libs which may reduce your overall binary size.

Increases memory usage, disk space, patch requirements and load time due to lack of shared library caching

Yes, at the cost of a bloated binary size.

But what if you link in just the functions you need, vs having the enormity of Library X on your disk that the package manager put there because it can’t know what you actually use/need?

Sure, but generally Library X is already on your system because someone else needs it. So why not use it if it's there?

Maybe you want it in a container with minimum dependency

Reply on news.ycombinator.com