Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 21:52 UTC (Wed) by Trelane (subscriber, #56877)
In reply to: Poettering: Revisiting how we put together Linux systems by mjthayer
Parent article: Poettering: Revisiting how we put together Linux systems

Pardon my ignorance, but what does, "correctly optimized" mean precisely?

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 22:03 UTC (Wed) by zlynx (guest, #2285) [Link] (6 responses)

I believe that a properly put together static library has multiple .o files inside it. Each .o file should be one function, possibly including any required functions that aren't shared.

This is because the static linker reads .a libraries and includes required .o files.

A badly put together static library has one, or just a few .o files in it. Using any function from the library pulls in all of the unrelated code as well.

Poettering: Revisiting how we put together Linux systems

Posted Sep 4, 2014 5:51 UTC (Thu) by mjthayer (guest, #39183) [Link] (5 responses)

Exactly. Actually something I would expect the compiler and linker to be able to handle, say by the compiler creating multiple .o files, each containing as few functions as possible (one, or several if there are circular references).

Poettering: Revisiting how we put together Linux systems

Posted Sep 4, 2014 6:55 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

That sounds like libraries and the loader on Pr1mos. If your library was recursive it could catch you out (and if you had different functions with the same name in different libraries).

Each time you loaded a library, it checked the list of unsatisfied functions in the program against the list of functions in the library, and pulled them across.

So if one library function referenced another function in the same library, you often had to load the library twice to satisfy the second reference.

I've often felt that was better than the monolithic "just link the entire library", but it does prevent the "shared library across processes" approach.

Cheers,
Wol

Poettering: Revisiting how we put together Linux systems

Posted Sep 4, 2014 7:20 UTC (Thu) by mjthayer (guest, #39183) [Link]

That is how static linking works today with the standard GNU toolchain. If you are linking a binary statically you sometimes have to include a given library twice on the linker command line for that reason.

Poettering: Revisiting how we put together Linux systems

Posted Sep 4, 2014 14:14 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Yeah. --ffunction-sections -fdata-sections -Wl,--gc-sections can do that, in theory, but it makes binaries a lot bigger (and thus *more* memory-hungry) due to ELF alignment rules, and is rarely tested, complicated, and extremely prone to malfunction as a result. Use if wizard or highly confident only.

Poettering: Revisiting how we put together Linux systems

Posted Sep 5, 2014 7:54 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

Yes, I can see that. Is there any reason though (I am asking you as you know considerably more about the subject than I do) why the linker would not be able to merge ELF sections during the final link if they were not yet relocated?

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 15:42 UTC (Mon) by nix (subscriber, #2304) [Link]

No reason that I can see (though obviously this must be an optional behaviour: some programs would really *want* one section per function, unlike people who are just using it for GCing.)