[cfarm-users] Static vdso on other architectures

[Rafael Avila de Espindola]

Doing this one architecture at a time is just me being careful. It is
entirely possible that it is all common code and the corresponding
change will work everywhere.

I just want to avoid finding out in 6 months about a regression on an
architecture I am not able to test on and then trying to figure out some
way to disable this on just that architecture.

Cheers,
Rafael

"Joseph Myers" <joseph at codesourcery.com> writes:

> On Sun, 2 Dec 2018, Rafael Avila de Espindola wrote:
>
>> I have enabled static vdso on every architecture I can test it. That is,
>> on every architecture in the gcc farm that can build glibc.
>
> Having such a series of patches for different architectures suggests to me
> that there is too much in architecture-specific code, and more of the vDSO
> handling should be in architecture-independent code in glibc - in general
> in recent years we've been trying to move more things to
> architecture-independent code, with a minimum of architecture-specific
> overrides where actually needed.
>
> Could you describe what is common and what is different between
> architecture vDSO support in the Linux kernel.  For example:
>
> * Do all architectures support a vDSO at all?
>
> * Are there functions that are present in the vDSO for all architectures,
> or is the set of functions completely architecture-specific?
>
> * For the syscall interface, we have the asm-generic interface that
> defines the preferred set of syscalls that all new architectures will use.
> Is there anything like that for the vDSO - a preferred vDSO interface we
> know all new Linux kernel architectures will use?  If there is, it would
> indicate what should be the default in architecture-independent code in
> glibc, and what should be considered a deviation needing an
> architecture-specific override.
>
> --
> Joseph S. Myers
> joseph at codesourcery.com