On Monday 29 July 2024 08:06:19 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> You've chosen i386, I presume, because all the arguments are passed on
> the stack instead of in registers. For clarity let's call it x86_32
> instead of i386.

No, let's not. Everyone calls it i386.

> The code I showed in my previous posts yesterday relied on the return
> address being on the top of the stack. But you think my code won't
> work.

I was hasty in my reply, because you need to store at least one thing to make
it work: the return address you replaced with yours. You can't keep it r10
because it's a volatile register. You can't use the stack because you have
none available. You have to use a thread-local variable and to make that
reentrant, you'd need to have a linked list of return addresses allocated
using the heap. So it's possible... just terribly cumbersome.

And of course, the compiler will never use the heap directly like that.

This usecase is WAY too niche and it's already solved for just logging. You
can't explain its needs with just the standard because the standard does not
recognise DLL boundaries and has no way of intercepting a function call. It
does not belong in the Standard. Just ask your compiler toolchain vendor to
add it as an extension.

> You also mentioned something about "Controlflow Enforcement
> Technology" -- let's see if we can trigger this protection mechanism.
> My GodBolt above doesn't break it. Can you break it, Thiago?

How do you know it doesn't break it? What CPU did you run it on? How did you
turn on CET for the application? It's not the machines that Matt has for
Godbolt: https://godbolt.org/z/5YbnMrvoq

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