Hi, Willy, Hi Thomas
Good news for us ;-)
Hi Zhangjin,
On Wed, Aug 02, 2023 at 01:21:50PM +0800, Zhangjin Wu wrote:
Hi, Willy, Thomas
Yuan is helping me to test this series and the tinyconfig series with the latest compilers.
His first test found this ppc support failed with stackprotector when using a newer compiler (I used an older compiler without stackprotector for ppc), I'm debugging it, so, please ignore this revision too, of course, if time allows, welcome to take a look at the other patches.
His other tests are trying to find out the exact poweroff support options for every architecture one by one, let's fill this gap ...
Thanks for notifying us. I strongly suggest that you leave ppc32 aside for now, until the rest is completely validated and merged. It turns
Thanks very much, but good progress here ;-)
I compared some compilers and at last got the root cause of the ppc32 failure with stackprotector.
//// gcc 13.1.0 from mirrors.edge.kernel.org
$ make run-user XARCH=ppc -j4 CC=/labs/linux-lab/prebuilt/toolchains/ppc64le/gcc-13.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc ... Segmentation fault (core dumped)
0 test(s): 0 passed, 0 skipped, 0 failed => status: success
See all results in /labs/linux-lab/src/linux-stable/tools/testing/selftests/nolibc/run.out
//// gcc 10 from ubuntu ppa
$ make run-user XARCH=ppc -j4 CC=/usr/bin/powerpc-linux-gnu-gcc-10 ... 165 test(s): 157 passed, 8 skipped, 0 failed => status: warning
See all results in /labs/linux-lab/src/linux-stable/tools/testing/selftests/nolibc/run.out
$ grep stack run.out 0 -fstackprotector [OK]
And then compared the assemblies, found gcc 13.1.0 insert a bad instruction at the beginning of _start() and break our stack eventually.
start: stwu 1,-16(1)
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")))
Benefit from the __no_stack_protetor macro, we have no need to input __optimize__("-fno-stack-protector") for every new architecture, it may be the time to only use __optimize__("-fno-stack-protector"), am I missing something?
out that your willingness to work around some of the oddities met on this one have resulted in a lot of drift away from the "keep it simple" principle and significantly delayed the possibilities to integrate the rest of your work. It would be much saner to only focus on ppc64/ppc64le and figure later how to make ppc32 work (or decide not to support it if it's not worth the effort in the end).
Another test shows, the run target of ppc64le with the big endian gcc 13.1.0 toolchain has test startup failure (although we have verified run-user before, run-user ok! and run with local powerpc64le toolchain ok too!), I'm debugging this now, hope it not cost too much.
Another good news is, Yuan has found a working defconfig for ppc32 which has poweroff support and he is helping me narrowing down the exact options, this will eventually make us happy ;-)
Thanks & Best regards, Zhangjin
Regards, willy