Discussion:
Static vdso on other architectures
(too old to reply)
Rafael Avila de Espindola
2018-12-02 02:39:45 UTC
Permalink
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.

Close calls are

mips: There a couple of working machines, but gcc is too old. In gcc22
there is a /opt/cfarm/gcc-latest, but it is a broken link.

arm: There are a few aarch64 machines, but gcc is too old. The one in
/opt/cfarm/gcc-latest seems to be aarch64 only. There is a
/opt/cfarm/arm-linux-gnueabi in gcc116, but it is a broken link.

I am happy to try to code the patches, but I need volunteers to test
them.

Cheers,
Rafael
Petar Jovanovic
2018-12-03 11:01:13 UTC
Permalink
Post by Rafael Avila de Espindola
Close calls are
mips: There a couple of working machines, but gcc is too old. In gcc22
there is a /opt/cfarm/gcc-latest, but it is a broken link.
Hi Rafael,

I can help with mips, just let me know what you would like to be tested.

Regards,
Petar
Joseph Myers
2018-12-03 18:30:19 UTC
Permalink
Post by Rafael Avila de Espindola
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
***@codesourcery.com
Rafael Avila de Espindola
2018-12-04 00:29:06 UTC
Permalink
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
Post by Joseph Myers
Post by Rafael Avila de Espindola
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
* 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
Loading...