C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 16:10 UTC (Thu) by nix (subscriber, #2304)
In reply to: C library system-call wrappers, or the lack thereof by rweikusat2
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.

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.)