This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Static vdso on other architectures
- From: Rafael Avila de Espindola <rafael at espindo dot la>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, GCC Compile Farm <cfarm-users at lists dot tetaneutral dot net>
- Date: Tue, 04 Dec 2018 00:29:06 +0000
- Subject: Re: Static vdso on other architectures
- References: <OXRQ4Mqr9_5N1XaDkEwQ9vSPdrAkyWZ-ZOeX8ACZecX3zMWQ7oCsTUWxC5os9p00JIEGJiJ1U3eUSBF7yJHBXGrTIKKD2c9DLAoy7GzGtA8=@espindo.la> <alpine.DEB.2.21.1812031826220.29495@digraph.polyomino.org.uk>
- Reply-to: Rafael Avila de Espindola <rafael at espindo dot la>
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@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@codesourcery.com