Szabolcs Nagy wrote: >On 28/10/17 05:08, Jeff Law wrote: > >> My hope would be that we simply don't ever use the params. They were >> done as much for *you* to experiment with as anything. I'd happy just >> delete them as there's essentially no guard rails to ensure their values >> are sane. > > so is there a consensus now that 64k guard size is what > gcc stack probing will assume?
I think right now only AArch64 will use a 64KB probe size which is always enabled. It is best to hardcode this so it can't be changed or turned off, inadvertently or not... > if so i can propose a patch to glibc to actually have > that much guard by default in threads.. (i think it > makes sense on all 64bit targets to have bigger guard > and a consensus here would help making that change) Assuming a minimum 64KB thread guard size on 64-bit systems is unlikely to be controversial - the guard size in OS/GLIBC may be larger than the probe size used in GCC, so I suggest to propose a patch. >>> Also on AArch64 --param=stack-clash-protection-probe-interval=16 causes >>> crashes due to the offsets used in the probes - we don't need large offsets >>> as we want to probe close to the bottom of the stack. >> Not a surprise. While I tried to handle larger intervals, I certainly >> didn't test them. Given the ISA I wouldn't expect an interval > 12 to >> be useful or necessarily even work correctly. > > it's not clear what makes probing at every 64k hard, > i think this should be clarified before we stick to > this design. (..or before backporting such patches) There is nothing inherently hard about large probe intervals. Any size can be supported efficiently on AArch64 (like I showed in my examples of expected code sequences for probes). Wilco
