On Wed, Aug 02, 2023 at 11:36:30PM +0200, Thomas Weißschuh wrote:
On 2023-08-03 00:03:58+0800, Zhangjin Wu wrote:
Hi, Willy, Hi Thomas
I'm so happy to share with you, we have solved all of the left found issues, include the ones about ppc and the missing poweroff options for the tinyconfig series, will renew both series ;-)
Can we stick to one series at a time?
Yes and please this time, let's stick exclusively to what is sufficiently tested for 6.6, otherwise it will have to be delayed.
Further compared the preprocessed files, found the root cause is the new compiler using 'no_stack_protector' instead of '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before.
I checked some of the other architectures, they didn't have the same issue, but test shows the 'no_stack_protector' attribute does have such compability issue here.
I learned the commit message of tools/include/nolibc/compiler.h, seems __optimize__("-fno-stack-protector") is enough for all of the nolibc supported architectures? is it ok for us to simply give up 'no_stack_protector' eventully? otherwise, we should manually disable 'no_stack_protector' for ppc32:
#define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector")))
Hello, any suggestion here? ;-)
Patience :-)
no_stack_protector is the offically documented mechanism to disable stack protector for a function. As it works for all other architectures this seems like a compiler bug.
Or a limitation. To be honest we're playing with compiler limits by adjusting their optimizations per function. But as long as we don't break what currently works, we can accept to have some limits in a first version (e.g. if ppc32 doesn't support -O0 for now it's not dramatic). Also, some other archs use optimize("Os", "omit-frame-pointer")), maybe that's needed there as well.
If we want to work around it I would prefer to have both attributes.
Also if you remember we also used to have a work-around for the function's entry code consisting in renaming _start and having a _start pointer in the asm code itself. That can remain an option to experiment with later. But let's not change everything again at the last minute, all these series have been sufficiently difficult to follow :-(
thanks, Willy