Date: Thu, 27 Jul 2023 08:33:50 -0700
On Wednesday, 26 July 2023 08:01:30 PDT Ofek Shilon via Std-Proposals wrote:
> There's actually another issue at play here - interposition: the practice
> of having a definition from one binary (typically the executable) override
> a definition from another binary (a shared library).
> The MS implementation doesn't have it, but any ELF system (that I know of)
> does.
And it's fragile and frowned upon everywhere, so I don't think this needs to
be discussed. It can be left as an extension supported by those systems.
For anyone attempting interposition, I'd also recommend you check the symbol
you're trying to interpose was developed with interposition in mind. The
compiler is freely allowed (and must remain so allowed) to inline the contents
of that function into other portions of the code. This means your
interposition is effectively a violation of ODR and you need to understand that
it may not take effect everywhere.
Furthermore, it is recommended that calls to local symbols resolve directly,
not via the PLT on ELF systems. This wasn't possible without program
modification until recently (the -mno-direct-extern-access flag and protected
visibility), but it now is. The recommendation is as early as the DSO HOWTO by
Ulrich Drepper.
> The existing ODR clause says (http://eel.is/c++draft/basic.def.odr#14) :
> "For any definable item D with definitions in multiple translation units
> ... the program is ill-formed". Interposition is the handling of a
> private case of this state: definitions in multiple *linkage* units.
> (BTW, in the particular case of replacement-functions (
> http://eel.is/c++draft/replacement.functions#3) I'd even say interposition
> is blessed by the standard. The replacement-functions clause does link to
> the ODR clause, but I can't see how that makes them reconcile.)
No, it's not. The replacement functions are a handful in the standard and
explicitly listed, so vendors know to take great care to allow them and to
avoid the inlining problem above. It's not a blanket permission to do
interposition to anything.
In particular, attempting to interpose any C library function is UB,
notwithstanding the fact that it works and is designed to work with glibc on
Linux.
> So to have the standard be pragmatic and take a step towards reality, I
> think the way is to introduce a notion of 'linkage-units' and restrict ODR
> to one such unit.
I agree we need some fixes and I do think we need to extend the language and
the standard to support the notion of shared libraries (or whatever name we
adopt to mean it). But not interposition.
> There's actually another issue at play here - interposition: the practice
> of having a definition from one binary (typically the executable) override
> a definition from another binary (a shared library).
> The MS implementation doesn't have it, but any ELF system (that I know of)
> does.
And it's fragile and frowned upon everywhere, so I don't think this needs to
be discussed. It can be left as an extension supported by those systems.
For anyone attempting interposition, I'd also recommend you check the symbol
you're trying to interpose was developed with interposition in mind. The
compiler is freely allowed (and must remain so allowed) to inline the contents
of that function into other portions of the code. This means your
interposition is effectively a violation of ODR and you need to understand that
it may not take effect everywhere.
Furthermore, it is recommended that calls to local symbols resolve directly,
not via the PLT on ELF systems. This wasn't possible without program
modification until recently (the -mno-direct-extern-access flag and protected
visibility), but it now is. The recommendation is as early as the DSO HOWTO by
Ulrich Drepper.
> The existing ODR clause says (http://eel.is/c++draft/basic.def.odr#14) :
> "For any definable item D with definitions in multiple translation units
> ... the program is ill-formed". Interposition is the handling of a
> private case of this state: definitions in multiple *linkage* units.
> (BTW, in the particular case of replacement-functions (
> http://eel.is/c++draft/replacement.functions#3) I'd even say interposition
> is blessed by the standard. The replacement-functions clause does link to
> the ODR clause, but I can't see how that makes them reconcile.)
No, it's not. The replacement functions are a handful in the standard and
explicitly listed, so vendors know to take great care to allow them and to
avoid the inlining problem above. It's not a blanket permission to do
interposition to anything.
In particular, attempting to interpose any C library function is UB,
notwithstanding the fact that it works and is designed to work with glibc on
Linux.
> So to have the standard be pragmatic and take a step towards reality, I
> think the way is to introduce a notion of 'linkage-units' and restrict ODR
> to one such unit.
I agree we need some fixes and I do think we need to extend the language and
the standard to support the notion of shared libraries (or whatever name we
adopt to mean it). But not interposition.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-07-27 15:33:53