|To:||Ralf Baechle <email@example.com>|
|Subject:||Re: OProfile cannot be loaded as module...|
|From:||David Daney <firstname.lastname@example.org>|
|Date:||Mon, 17 Oct 2005 13:14:01 -0700|
|User-agent:||Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)|
Ralf Baechle wrote:
On Fri, Oct 07, 2005 at 04:59:11PM -0700, David Daney wrote:arch/mips/oprofile/common.c defines several symbols (op_model_mipsxx and op_model_rm9000) with __attribute__((weak)). It then assumes that ELF linking conventions will prevail and there will be no problems if they are undefined.The problem is if you try to load oprofile as a module. The kernel module linker evidentially does not understand weak symbols and refuses to load the module because they are undefined.Actually it contains code to handle weak symbols so this is a bit surprising not last because STB_WEAK handling happen in the generic module loader code and is being used by other architectures as well. So if there's a problem with the module loader I'd prefer to solve that instead of starting to kludge around it.
Fine, but what exactly are the semantics of __attribute__((weak)) in modules? It gets resolved when linking with other objects that make up the module. But what if the weak symbol can be resolved at module load time against symbols in either the kernel proper or other modules? What happens if the weak symbol can be resolved by a symbol in a module that is loaded after the one with the weak symbol? Does it get fixed up when the new module is loaded?
What compiler exactly are you using btw?
GCC-3.4.3 / binutils 2.16.91 20050817 David Daney.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: IP28 patches, Stephen P. Becker|
|Next by Date:||[Patch] Fix lookup_dcookie for MIPS o32, David Daney|
|Previous by Thread:||Re: OProfile cannot be loaded as module..., Ralf Baechle|
|Next by Thread:||Re: OProfile cannot be loaded as module..., Ralf Baechle|
|Indexes:||[Date] [Thread] [Top] [All Lists]|