https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100665
--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> --- (In reply to Matthew Malcomson from comment #1) > Hi there. > I believe this is how it should work (if I'm understanding & remembering > correctly). > > When creating a nested function, we make a single object on the stack that > includes all variables used in the nested function plus a trampoline. > This is called the "nonlocal frame struct" as described in gcc/tree-nested.c. > > That single object gets a single tag like all other objects in tagged memory > (trying to separate the closed-over objects from the trampoline and argument > pointers would be pretty awkward when the object is just one struct as far as > the expand code is concerned). > > That tag is checked when accessing the closed over variables (i.e. big_array > in > the example), so we definitely want to tag the object. > This sounds reasonable. > Given that, the question of whether the function pointer (i.e. the pointer to > the trampoline inside that object) should be tagged when passed elsewhere > then > has a few benefits: > 1) In this case there is no check performed, but there may be checks > performed > if e.g. this function pointer gets cast to an integer pointer and some > code > elsewhere attempts to read that integer. I'm not sure there're cases where code pointers are casted to integer pointers. But consider the above comment, I agree that tag is needed for the object. BTW, I bring this up because I'm working on supporting hwsan with Intel LAM, but unlike TBI, Intel LAM only supports tagging of data pointer. So it looks like we need to mask off code pointers for indirect call or jmp in compiler-rt.
