Messages in this thread | | | Subject | Re: ppc/ppc64 and x86 vsyscalls | From | Benjamin Herrenschmidt <> | Date | Wed, 10 Mar 2004 08:33:13 +1100 |
| |
On Wed, 2004-03-10 at 08:14, Ulrich Drepper wrote:
> You can create one "big" DSO which covers all the configured processors. > Then at kernel start time, you determine the actual processor and > adjust the symbol table offsets to point to the correct version. There > is no requirement that the table used is identical to the one on disk. > It's loaded into ordinary memory which can be modified.
Ah, interesting.
> The tricky part of this would be to determine the symbol table slots. > But even this is quite simple. Just locate the symbol table in the > ELF-way, then iterate over the entries and use strcmp() for the names > and act upon match. What you shouldn't do is to generate pointer to the > symbol table entries somewhere. This is probably fragile and not worth > the few cycles you'll save.
Yes, make sense. I can "pre" prepare bth 32 and 64 bits DSOs at kernel start time, then I just have to map them. I suppose I should layout my DSO in such a way:
/* In one place the actual function implementation */ function_A_vers_1() function_A_vers_2() function_A_vers_3() function_B_vers_1() function_B_vers_2() etc .../...
/* Then, some empty "stubs" for the symbol table that gets really * linked into user binaries. Those are the symbol table entries * that get patched */ function_A() {} function_B() {}
Sounds right ? It's not completely obvious how I'll do to also map the 64 bits versions of these in the kernel address space, but I can find a trick.
Ben.
- 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/
| |