C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 13:22 UTC (Thu) by rweikusat2 (subscriber, #117920)
In reply to: C library system-call wrappers, or the lack thereof by mathstuf
Parent article: C library system-call wrappers, or the lack thereof

I don't think the idea of hard-coding a particular naming convention used by glibc in the linker would fly.

But this really isn't difficult to deal with at all if the library uses symbol versions consistently: Assuming the version symbol associated with the library version supposed to be targetted is YYZ. The dynamic symbol table of some newer version of the library will contain symbols labelled as @YYZ if and only if a newer, incompatible version exists (the default symbol version is denoted with @@). Hence, it's (as shown above) pretty trivial to create an include file fixing all changed symbols at version YYZ automatically.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 16:10 UTC (Thu) by nix (subscriber, #2304) [Link] (5 responses)

> I don't think the idea of hard-coding a particular naming convention used by glibc in the linker would fly.

You don't need to do that. You simply walk the symbol version table and note which symbol versions are ordered later than the requested maximum: then discard any symbol whose version is in that blacklisted set, and pick the latest version which is not blacklisted (determined from the same ordering). There's no dependency on the naming convention used by glibc at all in that, just a use of the already-recorded symbol version hierarchy.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 17:27 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (4 responses)

There is no such ordering: Version tags are just text.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

On their own, true, but there is a section of binaries which contains the hierarchy of symbol versions in the library. That is what gives the ordering, not the text of the symbol version itself.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:49 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

Version nodes don't need to have any kind of hierarchy.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:57 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Need? No. But glibc does provide it and I don't see why it couldn't be used.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 22:22 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite. If they don't provide a hierarchy in their version script, I think it's reasonable to assume that there is no ordering over the versions (which is a legitimate use of symbol versioning, though glibc doesn't use it where it should: GLIBC_PRIVATE is declared to depend upon the highest version currently in use rather than standing alone as it probably should.)