For 64-bit, the hack consists of a switch that chooses whether to use a
fixed address or a generically-assigned one, that's all there is to it.
So it costs about nothing.
Even for 32-bit, CONFIG_COMPAT_VDSO for a while now is doing nothing but
changing the default of the sysctl variable. There th
> I think you should drop CONFIG_COMPAT_VDSO support for 32-bit VDSO on
> 64-bit kernel. This was only to hack around a broken version of glibc
> that shipped with SUSE PRO 9.0,
I would be severly opposed to that. You cannot break compatibility to a large
chunk of userland. You would also break
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > The 32-bit vDSO mapping now behaves the same on x86_64 as on native
> > 32-bit. The abi.syscall32 sysctl on x86_64 now takes the same values
> > that vm.vdso_enabled takes on the 32-bit kernel. That is, 1 means a
> > randomized vDSO location, 2
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This makes x86_64's ia32 emulation support share the sources used in the
> 32-bit kernel for the 32-bit vDSO and much of its setup code.
>
> The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
> The abi.syscall32 sy
This makes x86_64's ia32 emulation support share the sources used in the
32-bit kernel for the 32-bit vDSO and much of its setup code.
The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
The abi.syscall32 sysctl on x86_64 now takes the same values that
vm.vdso_enabled take
5 matches
Mail list logo
