2024年9月28日 06:18,Jonas Oberhauser <jonas.oberhau...@huaweicloud.com> wrote: > > > > 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...
Let the p to be a static variable out of the function will make a difference. Or the following: int **p = &b; barrier_data(p); also works. BTW, barrier_data(&b) generates more instructions than godbolt when build the kernel. > > Have fun, > jonas > >