Messages in this thread |  | | From | Rusty Russell <> | Subject | Re: [MODULES] fix weak symbol handling | Date | Tue, 14 Jan 2003 14:11:30 +1100 |
| |
In message <20030113110036.A873@twiddle.net> you write: > I discovered this while working on oprofile for Alpha. I thought > I'd avoid a whole series of nested ifdefs by marking some symbols > weak, and so let them go undefined and resolve to null. Except > that we don't handle that in the new module loader. > > Fixed thus.
That part looks OK. The second loop was only there so we placed common symbols first: now we don't do that, your cleanup is a good idea. I'll extract and test that part.
> > I also correct a misconception in simplify_symbol. It is pointless > to lookup an undefined symbol in the module in which it is undefined.
<sigh>. I don't think so.
PPC64 (not in tree yet):
+ /* REL24 references to (external) .function won't + resolve; deal with that below */ + if (!sym->st_value + && ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24) { + printk("%s: Unknown symbol %s (index %u)\n", + me->name, strtab + sym->st_name, + sym->st_shndx); + return -ENOENT; + }
That's *why* find_symbol_internal() is not static, and why we don't fail in simplify_symbol() 8(
Hope that clarifies, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |