Re: ppc/ppc64 and x86 vsyscalls

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.