Re: Why disable vdso by default with CONFIG_PARAVIRT?

[Andi Kleen <ak@suse.de>]

> So the SUSE 9 

SL9.0 (not to be confused with SLES9). But it's all distributions
with an older glibc.

> libc needs COMPAT_VDSO, or it just can't deal with the 
> vdso moving around?  Can it deal with the current kernel's mobile vdso?

It needs COMPAT_VDSO

[which is basically COMPAT_NO_OLD_GLIBC and imho always
was a big mistake to have a config anyways -- one shouldn't gamble
with binary compatibility so lightly] 

> >> (in fact, its actually very useful so that it picks up the
> >> right libc with Xen-friendly TLS).
> >>     
> >
> > AFAIK libc selection comes from the aux vector, not the vdso.
> 
> No, it seems to be done by adding a .note segment to the vdso share
> object. 

Hmm, i had assumed it used the same mechanism as the CPU optimized
libcs -- and that comes from the aux vector AT_PLATFORM.  

> Without the vdso, my Xen test system doesn't boot because it 
> can't find the nosegneg versions of the libraries (it doesn't seem to
> know where to look).  I'm not sure how all this stuff fits together. 

Why does it not boot? At least in the past nosegneg was only a optimization
to avoid some unnecessary traps to the hypervisor, but it should handle it.
Has that changed?

> But the auxv is supposed to point to the vdso...

create_elf_tables() puts the AT_PLATFORM string onto the stack,
unless i'm misreading the code badly. No dependency on vdso.

-Andi