On Thursday 31 October 2024 04:55:33 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> So it's possible to intercept all the method calls on a polymorphic
> object without needing to allocate a page of writeable executable
> memory -- in fact it's possible without any dynamic allocation or
> permission setting at all.

You do realise you have an arbitrary constant of MAX_COUNT_METHODS in your
code, right? It's pretty easy to have classes with hundreds of virtuals.

You've still not listened to me when I said you're either saving too many
registers or too few. If you can intercept only at function call boundaries,
you only need to save the callee-preserve registers. None of the rest can be
relied upon to have any meaningful value upon entry in the function call nor
do they have to have any particular value on exit.

If you can intercept anywhere, then you must save ALL registers, not just a
fixed handful. You've missed half of all GPRs on x86-64 (r16 to r31) and seven
eighths of the vector register state. That is, you managed to miss 83.33% of
the state of a typical AVX10.2-512 application. Then we have extra states like
AMX (currently 8192 bytes) or MPX (128 bytes, but deprecated). And that's not
counting the fact that your POP_ALL macro is pushing the XMM registers, not
popping them.

Your code doesn't look thread-safe, even if the interception can only be done
at program start before threads. I also think it will fail at runtime if
Controlflow Enforcement is enabled, around lines 393-396.

> I think I'll put this into a debug library, along with some other
> interceptor-related and "man in the middle" stuff -- which I find
> immensely useful when debugging gets extreme (in particular when
> dealing with proprietary libraries for which I don't have the source
> code). It would be nice if stuff like this could go into the Standard
> under the namespace 'std::debug::', but I think it might be too much
> grief for the whole "object model" thingie if we were able to alter an
> individual object's vtable.

That's why it should be in tooling, not in the standard.

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