I'm curious with this compile-time/runtime representation difference. We
can sort things in compile time. If I make a sorted compile-time array of
function pointers (sorted by the regular "ptr < ptr" sense) and then in
runtime do a binary search to check if a certain function exists in that
array, would that be well-defined behaviour, and how?

// Robin

On Wed, Apr 30, 2025, 19:30 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> 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. 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
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>