Date: Wed, 30 Apr 2025 10:30:49 -0700
On Wednesday, 30 April 2025 01:29:21 Pacific Daylight Time Sebastian Wittmeier
via Std-Proposals wrote:
> In the post I was thinking about how it could be generally handled at
> _runtime_, too, to separate function addresses and identity. And do it also
> for other pointers to read-only objects. (I do not say const objects as
> const can be cast away under certain conditions.)
The original IA-64 C++ ABI proposal had it so function pointers were pointers
to a memory location containing the function's entry point and the target
module's gp register value. This was never realised and the first C++ builds I
had on IA-64 ditched the indirection. I think the ABI ended up requiring a
thunk to transfer control from one ELF module to the next, if the callee isn't
reloading its own gp. Unfortunately, I can't find an IA-64 compiler any more to
check what it did. In any case, retrofitting this would be a breaking change.
And even more so, it would break C too, so there's less than a snowball's
chance in hell of this ever happening for any extant platform.
What could be done is nominate a thunk as the function's identity. This is
very similar to what the PLTs in the executable are, for any non-modern build.
That would allow merged functions to exist in the same location in memory, but
if all but one of the functions have different entry thunks, then comparing
their function pointers would prove them different. The drawback with this is,
of course, that it adds a thunk, though if we're talking about merged
functions in a single module, those jumps would be unconditional PC-relative
and thus very fast.
It would set a minimum bar of merging, though. You'd never merge simple
functions that set the return value to some immediate value and return, maybe
not even load from memory and return, because you'd gain no space, given usual
function separation and some architectural requirements on alignment of their
pointers.
via Std-Proposals wrote:
> In the post I was thinking about how it could be generally handled at
> _runtime_, too, to separate function addresses and identity. And do it also
> for other pointers to read-only objects. (I do not say const objects as
> const can be cast away under certain conditions.)
The original IA-64 C++ ABI proposal had it so function pointers were pointers
to a memory location containing the function's entry point and the target
module's gp register value. This was never realised and the first C++ builds I
had on IA-64 ditched the indirection. I think the ABI ended up requiring a
thunk to transfer control from one ELF module to the next, if the callee isn't
reloading its own gp. Unfortunately, I can't find an IA-64 compiler any more to
check what it did. In any case, retrofitting this would be a breaking change.
And even more so, it would break C too, so there's less than a snowball's
chance in hell of this ever happening for any extant platform.
What could be done is nominate a thunk as the function's identity. This is
very similar to what the PLTs in the executable are, for any non-modern build.
That would allow merged functions to exist in the same location in memory, but
if all but one of the functions have different entry thunks, then comparing
their function pointers would prove them different. The drawback with this is,
of course, that it adds a thunk, though if we're talking about merged
functions in a single module, those jumps would be unconditional PC-relative
and thus very fast.
It would set a minimum bar of merging, though. You'd never merge simple
functions that set the return value to some immediate value and return, maybe
not even load from memory and return, because you'd gain no space, given usual
function separation and some architectural requirements on alignment of their
pointers.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-04-30 17:30:53