On Wed, 15 Oct 2014 11:05:41 -0600 Bjorn Helgaas <[email protected]> wrote:
> A common usage of "weak" is for a default implementation of a function.
> An architecture that needs something different can supply a non-weak
> ("strong") implementation, with the expectation that the linker will select
> the strong version and discard the weak default version.
>
> We have a few function declarations in header files annotated as "weak".
> That causes every *every* definition to be marked "weak", which means there
> is no strong version at all. In this case, the linker selects one of the
> weak versions based on link order. I don't think this is what we want.
>
> These patches remove almost all the weak annotations from header files
> (MIPS still uses it for get_c0_compare_int(), apparently relying on the
> fact that a weak symbol need not be defined at all). In most cases, the
> default implementation was already marked weak at the definition. When it
> wasn't, I added that.
>
> It might be simplest if I ask Linus to pull these all as a group from my
> branch [1]. I'll look for acks from the following people. If I don't see
> an ack, I'll drop the patch and you can take it yourself or ignore it as
> you wish.
>
> Eric: audit
> Thomas, Ingo, or Peter: x86
> Ralf: MIPS
> John or Thomas: clocksource
> Jason: kgdb
> Ingo: uprobes
> Andrew: vmcore, memory-hotplug
Acks, of course..
> I don't know whether these fix any actual bugs. We *did* have a bug like
> this on MIPS a while ago (10629d711ed7 ("PCI: Remove __weak annotation from
> pcibios_get_phb_of_node decl")), so it's possible that they do fix
> something.
I'm rather astonished that we haven't hit problems with this before
now.
This is pretty rude behaviour from the linker, really - grabbing the
first __weak function and using that is very likely to be the wrong
thing to do.
Still, this is a bit of a hand grenade and we should think up some way
of detecting/preventing recurrences.
I guess a checkpatch rule which warns about __weak and
__attribute__((weak)) in a header file would help. Is there anything
more robust we can do? Coccinelle, sparse, etc?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
