Re: huge gcc 4.1.{0,1} __weak problem

From: Jeremy Fitzhardinge
Date: Fri May 02 2008 - 17:10:23 EST


Adrian Bunk wrote:
On Wed, Apr 30, 2008 at 05:49:46AM -0700, Pallipadi, Venkatesh wrote:
-----Original Message----- From: David Miller From: Venki Pallipadi <venkatesh.pallipadi@xxxxxxxxx> Date: Tue, 29 Apr 2008 18:31:09 -0700

Some flavors of gcc 4.1.0 and 4.1.1 seems to have trouble
understanding
weak function definitions. Calls to function from the same
file where it is
defined as weak _may_ get inlined, even when there is a
non-weak definition of
the function elsewhere. I tried using attribute 'noinline'
which does not
seem to help either.

One workaround for this is to have weak functions defined in
different
file as below. Other possible way is to not use weak
functions and go back
to ifdef logic.

There are few other usages in kernel that seem to depend on
weak (and noinline)
working correctly, which can also potentially break and
needs such workarounds.
Example -
mach_reboot_fixups() in arch/x86/kernel/reboot.c is one such
call which
is getting inlined with a flavor of gcc 4.1.1.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx>
Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
This sounds like a bug. And if gcc does multi-file compilation it
can in theory do the same mistake even if you move it to another
file.

We need something more bulletproof here.

The references here
http://gcc.gnu.org/ml/gcc-bugs/2006-05/msg02801.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781

seem to suggest that the bug is only with weak definition in the same
file.
So, having them in a different file should be good enough workaround
here.
...

A workaround here is the wrong solution since this isn't the only place that suffers from this issue.

We currently give a #warning for 4.1.0.
But not for 4.1.1.
(Accordingto the bug >= 4.1.2 is fixed.)

And a #warning is not enough.

The huge problem is that "empty __weak function in the same file and non-weak arch function" has recently become a common pattern with several new usages added during this merge window alone.

And the breakages can be very subtle runtime breakages.

I see only the following choices:
- remove __weak and replace all current usages
- move all __weak functions into own files, and ensure that also happens
for future usages
- #error for gcc 4.1.{0,1}

- make __weak also include noinline. I think that's sufficient (at least it was when I encountered a gcc bug with these symptoms last year or so).

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/