LWN: Comments on "A look at dynamic linking"

A look at dynamic linking

Vorpal — Thu, 22 Feb 2024 09:56:14 +0000

I hadn't heard of that. Reading about it, it sounds similar to the old prelink utility. Maybe it even is what prelink used internally?

I used to do tons with LD_PRELOAD

nix — Wed, 21 Feb 2024 12:22:21 +0000

Nowadays, if you want to do something like that and also explore exciting underused parts of ld.so, the thing to try is LD_AUDIT libraries. These are loaded in a new dlmopen namespace, so they can rely on other shared libraries and the like, making it a lot easier to write the things than it is to write an LD_PRELOADed profiler.

(In practice this excellent feature is rarely used, alas.

A look at dynamic linking

nix — Wed, 21 Feb 2024 12:19:16 +0000

Ah, thanks for that: I was sure there were awful dependency-related subtleties involved but had entirely forgotten what they were! (IIRC that in the early days IFUNCs were just executed whenever, with no particular guarantees about what if anything else had been relocated. Surprisingly, even this was enough to do a lot of useful things with them.)

A look at dynamic linking

mechanicker — Mon, 19 Feb 2024 15:14:49 +0000

Remembering the time when I used `dldump` to generate a new executable with most relocations done to speed up start time of a popular CAD software that would load a lot of dynamic libraries.
This was inspired by the Emacs build system and their portable dumper mechanism.

A look at dynamic linking

fw — Sat, 17 Feb 2024 08:33:59 +0000

Some targets require relocation processing for static functions and global data access, too. The way that this is supposed to work is that objects make their dependencies explicit using DT_NEEDED. This way, the dynamic linker can compute a relocation order that processes the object containing the IFUNC before the object that invokes.

In practice, this does not always work with symbol interposition, which is not refected in the DT_NEEDED dependencies:

Bug 20188 - libpthread IFUNC resolver for vfork can lead to crash

A look at dynamic linking

jcpunk — Thu, 15 Feb 2024 16:07:41 +0000

This is the kind of technical content I love to see at LWN!

A look at dynamic linking

andi8086 — Thu, 15 Feb 2024 08:51:52 +0000

Thank you, that's exactly why I pay for LWN :D To learn deep technical stuff...

A look at dynamic linking

interalia — Wed, 14 Feb 2024 23:42:28 +0000

Thanks for this article. Knew a decent amount of this but it's always nice to get a well written description with some of the finer details!

A look at dynamic linking

nix — Wed, 14 Feb 2024 12:50:06 +0000

This too is largely the dynamic linker's job, yes: the linker proper just translates the ifuncs GCC emits into STT_GNU_IFUNC-type symbols in the final ELF object.

As an aside, there are fairly harsh restrictions on what ifuncs can do -- notably, since they're called in the middle of dynamic symbol resolution, they can't call anything else which might go through the dynamic linker, which more or less means static functions only.

A look at dynamic linking

cyperpunks — Wed, 14 Feb 2024 09:29:11 +0000

Seems like the details of rpath/runpath was skipped in the description?

Lazy dynamic linking problem

jreiser — Wed, 14 Feb 2024 04:01:28 +0000

Lazy dynamic linking defers binding to any particular external procedure until the first actual use. This avoids work for resolving references to unused symbols, but can also plant a time bomb if there is no definition for a symbol that is used eventually. So a program might fail unexpectedly when it enters a new phase of execution that uses previously-unused symbols. This can be particularly troublesome if the dependent shared libraries are not careful enough to implement an ABI that supports software evolution through differing delivered versions. BIND_NOW can be useful during development and maintenance, for the purpose of finding such dangling references.

I used to do tons with LD_PRELOAD

davecb — Tue, 13 Feb 2024 20:53:53 +0000

In a previous life, interposing things between caller and recipient was a favourite task.
We used it to create programs like a low-overhead strace, a performance measurement tool that used unmodified binaries, and, as a demo, a Linux library profiler, https://github.com/davecb/libprof

A look at dynamic linking

jengelh — Tue, 13 Feb 2024 20:22:36 +0000

Yeah I only noticed it afterwards. There's a simple fix that could be applied to the LWN CSS globally: `pre { white-space: pre-wrap; }`.

A look at dynamic linking

WolfWings — Tue, 13 Feb 2024 19:25:07 +0000

BTW, the way you structured several lines as 'one enormous one-liner' really blows out the formatting of the site due to your comment.

There's never any reason to have a bunch of commands on one line linked with ; like that, just use extra lines. :)

A look at dynamic linking

jengelh — Tue, 13 Feb 2024 18:08:18 +0000

>[PT_INTERP element in the program header.] When present, this element indicates that the program is dynamically linked.

On the contrary. You can have a PT_INTERP defined and still be statically linked, for the most prominent definitions of "static"—free of extra libraries and relocations. The interpreter could do whatever it pleases, but for brevity, I'll just let it loop:

/tmp$ cat x.s
_start:
        jmp _start
.globl _start
/tmp$ gcc -c x.s; ld -o loader x.o; ld -shared -o loader.so x.o; ld -dynamic-linker /tmp/loader -o a.out x.o /tmp/loader.so; objcopy -R .dynamic a.out b.out

(GNU ld requires at least one DT_DYN file, else it will not copy the -dynamic-linker argument into a.out. Thus we're getting rid of the DT_NEEDED:loader.so entry again with objcopy.) So here we have a static program (b.out) with an interpreter. glibc, musl and file all are readily confused about the file, too:

# /usr/bin/file b.out
b.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /tmp/loader, not stripped
# ldd b.out
        not a dynamic executable
# ld.so --list b.out
b.out: error while loading shared libraries: b.out: cannot open shared object file (?!)
# /var/lib/machines/alpine/lib/ld-musl-x86_64.so.1 --list b.out
        /tmp/loader (0x7f5d806b7000)

Well, musl got it right.

A look at dynamic linking

abatters — Tue, 13 Feb 2024 16:04:59 +0000

Does the linker handle indirect functions?

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Func...