Re: [GIT pull] x86 vdso updates

[richard -rw- weinberger]

On Fri, May 27, 2011 at 5:05 PM, Andrew Lutomirski <luto@xxxxxxx> wrote:
> On Fri, May 27, 2011 at 10:59 AM, richard -rw- weinberger
> <richard.weinberger@xxxxxxxxx> wrote:
>> On Fri, May 27, 2011 at 2:10 PM, Andrew Lutomirski <luto@xxxxxxx> wrote:
>>> On Fri, May 27, 2011 at 7:59 AM, richard -rw- weinberger
>>> If this is considered enough of a regression, then I guess we can
>>> leave vsyscall64 around for awhile, but it will require extra work in
>>> the soon-to-be syscall emulation hack to make sure that UML can still
>>> trap the syscall.
>>
>> As long the time within UML is synchronous with the host everything is
>> fine, right?
>
> I think so.  I haven't used UML in a long time.
>
>> So, as _last_ choice we could disable the ability to change the time within UML.
>>
>> IMHO it's not a big deal when getcpu() returns a wrong CPU layout on UML.
>>
>>> The real solution is to fix glibc to use the vDSO which should avoid
>>> this problem entirely.
>>

Yesterday I had a closer look at 64bit UML.
Glibc is always using vsyscalls because 64bit UML does not support the vDSO.

On 32bit UML simply scans the ELF auxiliary vector provided by the host to
get the address of the vDSO.
How can I get this address on a 64bit host?

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/