Hi,
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.
Yes, ppc series at first, will renew it today. let's delay the whole tinyconfig series (include part1) in v6.7, we have no enough time to test them carefully for v6.6.
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.
Since it is really related, let's summarize yesterdays's further test here for a reference:
Yesterday's test result on randomly chosen x86_64 and riscv64 shows, from at least gcc 12.3.0 (may differs from archs), even with optimize("Os", "omit-frame-pointer")), whatever with or without '-fno-stack-protector', -O0 forbids the per function's "omit-frame-pointer" as the doc [1] describes (as we discussed before), that means some imtermediate gcc versions deviate from their docs and now, the latest gcc version come back to follow its doc [1] and become even more strict and then breaks our optimize("Os", "omit-frame-pointer") workaround eventually:
Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified.
So, it is ok for us to simply ignore -O0 currently, let's work on them in v6.7.
[1]: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html
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.
Yes, the 'asm' style of _start may be a choice to prevent gcc touching our startup code.
But let's not change everything again at the last minute,
It is reasonable.
all these series have been sufficiently difficult to follow :-(
Thanks, Zhangjin
thanks, Willy