Date: Sun, 11 May 2025 23:59:01 -0400
On 4/30/25 1:30 PM, Thiago Macieira via Std-Proposals wrote:
> 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.
IIRC, the above describes how function pointers are implemented for AIX
on Power machines.
Tom.
> 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.
>
> 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.
IIRC, the above describes how function pointers are implemented for AIX
on Power machines.
Tom.
> 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.
>
Received on 2025-05-12 03:59:03