On Friday, 20 May 2022 16:29:22 PDT Edward Catmur wrote:
> That's a very good point, and I'm embarrassed to have not seen it. Would it
> be viable to make a path for implementors to provide a facility for
> libraries to opt out of the ABI break on function argument passing?
>
> How about making the relocation mechanism on function parameters
> implementation-defined (i.e. the implementation is permitted to select
> move+destroy, even if a relocator proper is also available); then compilers
> can create an attribute [[no_relocate_abi]] (possibly standardized,
> although I'm not sure that's necessary), and libraries can put that
> attribute on classes (or their relocate operators) if they want efficient
> relocation available to containers but to still use the old ABI for
> function argument passing. The attribute would need to propagate from bases
> and members to the inheriting or containing class.

I don't think that's sufficient. The change needs to be opt-in, not opt-out.
Otherwise, we're going to have silent breakages because of some libraries
recompiled and others not.

Moreover, it needs to be opt-in per call site, not per type. One library
declaring a type cannot know where that type gets used: it might be used by
another library in its own ABI. So even if the first library has no ABI break,
another one downstream of it might. As an example of std::unique_ptr,
currently libc++ has no functions defined in its ABI that take it as a
parameter:

$ nm -DC --defined /lib64/libc++.so.1 | grep -c ' T .*unique_ptr'
0

So if libc++ opted in, it would see no difference in its binary. But the next
level would:

$ nm -DC --defined /lib64/libgpgmepp.so.6 | grep ' T .*unique_ptr'
00000000000238e0 T GpgME::Context::startEditing(GpgME::Key const&,
std::unique_ptr<GpgME::EditInteractor,
std::default_delete<GpgME::EditInteractor> >, GpgME::Data&)
[...]

Without any markers, this would cause a resource leak. It's pretty clear there
would be a marker somewhere, like the __attribute__((abi_tag)), which means
this wouldn't be a silent breakage, but it would still be a break. This is
exactly what happened to std::string in libstdc++, when it went from
std::basic_string<...> to std::__cxx11::basic_string<...>.

The problem with opt-in, of course, is that too few people will remember to
opt in.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering