On 7/7/21 10:39 PM, Arnd Bergmann wrote:
On Wed, Jul 7, 2021 at 3:36 PM Helge Deller <deller@xxxxxx> wrote:
* Arnd Bergmann <arnd@xxxxxxxx>:
My first thought was this was a result of -finline-functions getting
enabled by default in gcc-10, but enabling it on gcc-9 did not
help here. It's likely that the gcc behavior was fixed in the process
of enabling the more aggressive inliner by default though.
I also tried building genhd.o for every architecture that has
gcc-9.4 support and did not find the problem anywhere except
on parisc.
Using CONFIG_CC_OPTIMIZE_FOR_SIZE did solve the
problem for me (frame size down to 164 bytes), but I could not
pinpoint a specific -f option that fixes it for -O2. Maybe we can
simply change the defconfig here? 32-bit parisc systems are
probably memory limited enough that building a -Os kernel
is a good idea anyway. 64-bit parisc already builds with -Os
but does not see the warning with -O2 either.
I agree that the simplest solution is to increase the default value for
parisc here.
On parisc we have a 32k stack (either 1x32k or 2x16k when using IRQ
stacks). I increased the default value to 1280 in 2017, but as can be
seen here this isn't sufficient. Either way, we have an active runtime
check for stack overflows which has never triggered yet, so let's just
remove the compiler warning by increasing the value to 2048. Patch is
below.
[PATCH] parisc: Increase gcc stack frame check to 2048 for 32- and 64-bit
parisc uses much bigger frames than other architectures, so increase the
stack frame check value to 2048 to avoid compiler warnings.
I think setting it to 2048 is rather excessive,
Since parisc needs roughly twice the frame (and stack) size as x86,
2048 seemed logical since that's the double of what's used on x86.
Of course we can reduce it, e.g. to 1536.
and it would make you miss other real bugs. What I suggested was to
change the defconfig to use CONFIG_CC_OPTIMIZE_FOR_SIZE instead.
But then you still will see those warnings in case you choose to not
optize for size.
The reasoning for the 1280 byte limit on parisc is that it needs a few extra
bytes for its larger stack frames, and 1024 for the other 32-bit architectures
is only there because anything smaller warns for a handful of functions
that are fine-tuned to need slightly less than that, when the call chain
is predictable and using less would impact performance.
I actually think we should reduce the warning limit for 64-bit architectures
to 1280 bytes as well, but that triggers a couple of warnings that still
need to be resolved first. In almost all cases, a kernel function needing
more than 512 bytes is an indication of either a bug in the kernel, or
(rarely) in the compiler.
or bad coding, e.g. huge local variables ot too much nesting of local functions.
Helge
