On Thursday 17 October 2024 11:05:17 GMT-7 Thiago Macieira via Std-Discussion
wrote:
> > What happens when dynamic loading gets involved?
>
> It's a per shared-object/DLL array. You can't merge multiple arrays from
> different objects, because they would never be contiguous in memory.

Actually, it might be possible the same way that thread_local data is merged
at runtime. This would only work for content that is loaded before main(),
though: anything loaded by plugins (including their libraries) can't be
merged.

The drawback of this is that the start and end pointers are not known at link
time, calculatable using PC-relative addressing. But they can be regular,
indirect references through the GOT. That would mean a static-storage variable
declaration like:

std::span<struct test> regular_tests = { &__start_tests, &__stop_tests };

Would live on .data.rel.ro and would be updated by the dynamic linker through
relocations once it finalised allocating the array in memory.

This global merging feature could be disabled by marking the variable static
or using hidden or protected visibility.

Of course, this would require new relocation types and updates to the linkers
and dynamic linkers in all modern OSes. For Linux/glibc, this is probably
doable; we have new ELF relocation types all the time, though they're usually
platform-specific and meant to improve performance and/or security. Once Linux/
glibc has it, the getting it into the other open source ELF systems, Linux/
Bionic (Android) and Linux/MUSL should be doable too. It would only be a
matter of having interested volunteers.

For platforms with proprietary dynamic linkers, I have no clue how to convince
their vendors. How does one convince Apple to change dyld? I wouldn't hold my
hopes up of getting this in QNX or Solaris inside of 15 years (if ever, in the
case of Solaris) -- they haven't implemented proper C++11 thread_local support
yet, for example.

And forget about changing Windows. But on Windows, DLLs are not considered
"other TUs of the same program" but more like "other programs that happen to
share address space" and have a lot of other compatibility issues with C++
compliance that will likely never be fixed (example: abort() and _exit() still
run DLLs' global destructors).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering