Date: Sat, 18 Apr 2026 21:08:41 -0700
On Saturday, 18 April 2026 17:38:20 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> My own thread describes a runtime feature, whereby you can at runtime
> replace the address of a function with the address of an 'interceptor'
> which will do some processing (e.g. logging, debugging, change global
> state) and then jump to the original function. My own feature can
> intercept a function of any signature (i.e. any return type, any
> number of arguments of any type, and can even be a member function),
> as the stack and all argument registers are preserved. That is to say,
> the entire call state is saved and then later restored. Note that my
> interceptor functions return void and take no arguments. Note that my
> [[interceptor]] attribute is placed on the interceptor function -- not
> on the function being intercepted. The interception happens at runtime
> when a function pointer (such as returned from 'dlsym' or
> 'GetProcAddress') is replaced with the address of an interceptor which
> does some processing and then jumps to the original function. No
> marking of the intercepted function takes place.
In other words, it does not apply to functions that were:
a) inlined (same TU or, with LTO, across TUs)
b) called through non-symbolic means - that is, via simple displacement
If you don't decorate the functions that are interceptible, then you cannot
guarantee that intercepting all calls.
Is that a problem for your use-case?
And more importantly: is this a problem for the feature if it came to be part
of the Standard?
> There's a separate thread by Zhao YunShan about what could be
> described as compile-time interception. Zhao describes a feature
> whereby the intercepted function is marked, and the interception is
> done at compile-time by the compiler, it's hard-coded into the binary.
> It's similar to the GNU "--wrap" feature.
>
> From now on, could I ask that we edit the subject line on future posts
> so that people know what's being talked about.
>
> My own thread = Interceptor Functions [runtime]
> Zhao's thread = Interceptor Functions [compile-time]
No.
First, threads are threads. Most people don't change the subject. So if you
start a thread with a subject, it will stay. So you and YunShan decide the
subject.
Second, the two features are too similar to be accepted separately in the
standard, or even be discussed. Either of them being proposed would trigger a
discussion about the other side. Therefore, no matter what separation you may
have, the efforts will bleed into one another.
Gotham via Std-Proposals wrote:
> My own thread describes a runtime feature, whereby you can at runtime
> replace the address of a function with the address of an 'interceptor'
> which will do some processing (e.g. logging, debugging, change global
> state) and then jump to the original function. My own feature can
> intercept a function of any signature (i.e. any return type, any
> number of arguments of any type, and can even be a member function),
> as the stack and all argument registers are preserved. That is to say,
> the entire call state is saved and then later restored. Note that my
> interceptor functions return void and take no arguments. Note that my
> [[interceptor]] attribute is placed on the interceptor function -- not
> on the function being intercepted. The interception happens at runtime
> when a function pointer (such as returned from 'dlsym' or
> 'GetProcAddress') is replaced with the address of an interceptor which
> does some processing and then jumps to the original function. No
> marking of the intercepted function takes place.
In other words, it does not apply to functions that were:
a) inlined (same TU or, with LTO, across TUs)
b) called through non-symbolic means - that is, via simple displacement
If you don't decorate the functions that are interceptible, then you cannot
guarantee that intercepting all calls.
Is that a problem for your use-case?
And more importantly: is this a problem for the feature if it came to be part
of the Standard?
> There's a separate thread by Zhao YunShan about what could be
> described as compile-time interception. Zhao describes a feature
> whereby the intercepted function is marked, and the interception is
> done at compile-time by the compiler, it's hard-coded into the binary.
> It's similar to the GNU "--wrap" feature.
>
> From now on, could I ask that we edit the subject line on future posts
> so that people know what's being talked about.
>
> My own thread = Interceptor Functions [runtime]
> Zhao's thread = Interceptor Functions [compile-time]
No.
First, threads are threads. Most people don't change the subject. So if you
start a thread with a subject, it will stay. So you and YunShan decide the
subject.
Second, the two features are too similar to be accepted separately in the
standard, or even be discussed. Either of them being proposed would trigger a
discussion about the other side. Therefore, no matter what separation you may
have, the efforts will bleed into one another.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-19 04:08:44
