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 -0700The references here
Some flavors of gcc 4.1.0 and 4.1.1 seems to have troubleunderstanding
weak function definitions. Calls to function from the samefile where it is
defined as weak _may_ get inlined, even when there is anon-weak definition of
the function elsewhere. I tried using attribute 'noinline'which does not
seem to help either.different
One workaround for this is to have weak functions defined in
file as below. Other possible way is to not use weakfunctions and go back
to ifdef logic.weak (and noinline)
There are few other usages in kernel that seem to depend on
working correctly, which can also potentially break andneeds such workarounds.
Example -call which
mach_reboot_fixups() in arch/x86/kernel/reboot.c is one such
is getting inlined with a flavor of gcc 4.1.1.This sounds like a bug. And if gcc does multi-file compilation it
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx>
Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
can in theory do the same mistake even if you move it to another
file.
We need something more bulletproof 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}