CODEWITHSUNDEEP
gccelfshared-libraries
user1226105
user1226105

Reputation: 71

Entire shared object loaded to RAM or only used symbols?

I'm currently implementing an embedded Linux based system. The persistent data is loaded from a NAND flash. One of the first applications in userland is using some functions of libglib. For the system, a low startup time is very important.

Because glib is large and NAND is slow, many people argue that the start is slowed down, because the entire glib has to be loaded to RAM! I don't believe in this "urban legend". My points are:

  1. The gcc linker supports lazy loading
  2. A shared library is handled like a memory mapped file. Therefore, the entire library is NOT loaded to RAM, but only sections containing the symbols, when they are accessed.

Are my assumptions correct and does someone have a reference to a text describing the loading of shared objects (not the symbol resolution with GOT, but the "loading" into RAM)?

Many thanks in advance!

Best regards Jean-Pierre

Upvotes: 3

Views: 386

Answers (1)

Employed Russian
Employed Russian

Reputation: 213955

My points are:

The gcc linker supports lazy loading

There is no such thing as "gcc linker", and (static) linker has nothing to do with anything.

A shared library is handled like a memory mapped file. Therefore, the entire library is NOT loaded to RAM, but only sections containing the symbols, when they are accessed.

This is correct: Linux will do demand paging from "disk", so if your disk is actually flash, and if you don't use compressed filesystem, and if your shared library is correctly built with no text relocations (-Wl,-z,text), then only referenced parts of code and data from the library will be paged into RAM.

Upvotes: 1

Related Questions