Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
On 2024-09-27 21:23, Jonas Oberhauser wrote:
[...]
That idea seems to be confirmed by this (atrocious, not to be copied!)
example:
int fct_escape_address_of_b(void)
{
int *a, *b;
do {
a = READ_ONCE(p);
asm volatile ("" : : : "memory");
b = READ_ONCE(p);
} while (a != b);
// really really hide b
int **p = &b;
OPTIMIZER_HIDE_VAR(p);
asm volatile ("" : : : "memory");
return *b;
}
This also does not generate any additional instructions, unlike just
using OPTIMIZER_HIDE_VAR(b).
What is the advantage of defining OPTIMIZE_HIDE_VAR the way it
currently works instead of like above?
Did you try it on godbolt.org ? Does it have the intended effect ?
I certainly did try and certainly read it as having the intended effect,
otherwise I wouldn't have written that it seems confirmed.
However, just because my eyes read it doesn't mean that's what happened,
and even if it happened doesn't mean that it is guaranteed to happen.
By the looks of it, you're just creating another version of @b called
"p", which is then never used and would be discarded by further
optimization. >
I'm unsure what you are trying to achieve here.
Simply put I'm trying to let the compiler think that I leaked the
address of b. After that, the memory barrier should let it think that
the b after the memory barrier might not be the same as the one before
it (which was equal to a), forcing it to read from b.
However, I suppose on second thought that that might not be enough,
because the compiler could still simply do b = a right after exiting the
while loop.
And that is true no matter what we put behind the while loop or before
the condition, as long as the condition compares a and b, right after it
the compiler can do b = a. Just took me a while to see :))
I'm not sure why gcc does the b=a with the normal OPTIMIZER_HIDE_VAR but
(as far as I read the code) doesn't do it with the above. Maybe just a
weird corner case...
Have fun,
jonas
