On Jan 7, 2024, "Kewen.Lin" <li...@linux.ibm.com> wrote: > As PR113100 shows, the unbiasing introduced by r14-6737 can > cause the scrubbing to overrun and screw some critical data > on stack like saved toc base consequently cause segfault on > Power.
Ugh. Sorry about the breakage, and thanks for addressing it during my absence. Happy GNU Year! :-) > By checking PR112917, IMHO we should keep this unbiasing > guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 && > TARGET_STACK_BIAS), similar to some existing code special > treating SPARC stack bias. I'm afraid this change will most certainly regress 32-bit sparc, because of the large register save area. I had been hesitant to introduce yet another target configuration knob, but it looks like this is what we're going to have to do to accommodate all targets. > I also expect the culprit commit can > affect those ports with nonzero STACK_POINTER_OFFSET. IMHO it really shouldn't. STACK_POINTER_OFFSET should be the "Offset from the stack pointer register to the first location at which outgoing arguments are placed", which suggests to me that no data that the callee couldn't change should go in the area below (or above) %sp+S_P_O. ISTM that PPC sets up a save area between the outgoing args and the stack pointer; I don't think that's very common, but I suppose other targets that do so would also define STACK_POINTER_OFFSET to nonzero so as to reserve those bits. But whether they should be cleared by stack scrubbing, as on sparc, or preserved, as on ppc, depends on the ABI conventions, so we probably can't help yet another knob :-/ I'll take care of that, and update the corresponding documentation. Thanks, -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
