This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Static vdso on other architectures
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Rafael Avila de Espindola <rafael at espindo dot la>
- Cc: <libc-alpha at sourceware dot org>, GCC Compile Farm <cfarm-users at lists dot tetaneutral dot net>
- Date: Mon, 3 Dec 2018 18:30:19 +0000
- Subject: Re: Static vdso on other architectures
- References: <OXRQ4Mqr9_5N1XaDkEwQ9vSPdrAkyWZ-ZOeX8ACZecX3zMWQ7oCsTUWxC5os9p00JIEGJiJ1U3eUSBF7yJHBXGrTIKKD2c9DLAoy7GzGtA8=@espindo.la>
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