2024年9月29日 06:10,Alan Huang <mmpgouride@xxxxxxxxx> wrote: > > 2024年9月28日 06:18,Jonas Oberhauser <jonas.oberhauser@xxxxxxxxxxxxxxx> 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); Or the following: int **t = &b; WRITE_ONCE(t, &b); barrier(); return *b; also works. > > also works. > > BTW, barrier_data(&b) generates more instructions than godbolt when build the kernel. > >> >> Have fun, >> jonas