https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917
--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Ok, I understand the issues now. The problem on sparc32 is indeed the large register save area that __strub_leave allocates, that overlaps with stack space it's expected to scrub, and that thus doesn't get scrubbed. There's no inherent reason for __strub_leave to allocate a stack frame, the only reason it does is because of -fPIC. Compiling strub.c with -fno-PIC on sparc solves the problem, without any ill effects on libgcc_s.so (no global variables, no function calls), so I'm probably going with it. I have a patch that gets all strub tests to pass. The remaining problem on sparc64 is the bias in the stack pointer: the used stack space is usually outside the range delimited by the biased stack pointers. My plan to fix this is to modify __builtin_stack_address to return the unbiased address, as long as __builtin_frame_address is unbiased, or otherwise introduce target-specified unbiasing for them where the strub machinery currently uses the stack-pointing (biased) registers.
