Hi,
> On Wed, Aug 02, 2023 at 11:36:30PM +0200, Thomas Wei�chuh 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
