On Thu, Aug 03, 2023 at 10:58:55AM +0800, Zhangjin Wu wrote:
> 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.
Thanks.
> > > > > 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.
Note that the quoted paragraph above is mostly independent. The point
here is that optimize("-Os") seems to be ignored then -O0 is passed
on the command line. But I'm not that much surprised, because as we
said, changing optimizations on the fly is tricky given that some have
effects beyond just a function.
> So, it is ok for us to simply ignore -O0 currently, let's work on them
> in v6.7.
Yeah I'm fine with this. In the worst case those using -O0 can also avoid
using stack-protector.
> > > 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.
That was the case. We had an earlier version where _start was a label
inside the asm statement, resulting in some unused prologue and epilogue
for the function around that code. It was a bit ugly and I think it had
some shortcomings but we may go back to that later if it brings some
value.
Willy
