This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Upstreaming the glibc Hurd port
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Samuel Thibault <samuel dot thibault at gnu dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, Thomas Schwinge <thomas at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, <bug-hurd at gnu dot org>, David Michael <fedora dot dm0 at gmail dot com>
- Date: Mon, 2 Apr 2018 14:17:38 +0000
- Subject: Re: Upstreaming the glibc Hurd port
- References: <alpine.DEB.2.20.1801182304260.26137@digraph.polyomino.org.uk> <20180118235924.r4z4ppvj7xlvmmfp@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801190030000.26137@digraph.polyomino.org.uk> <87a7xaupjx.fsf@euler.schwinge.homeip.net> <alpine.DEB.2.20.1801191721480.329@digraph.polyomino.org.uk> <20180124011051.5s2vugyq3ybnurwc@var.youpi.perso.aquilenet.fr> <20180124012726.tibylwp4re5dtgc3@var.youpi.perso.aquilenet.fr> <20180125014143.2hxhzon5lzxtqq6j@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801251544550.22734@digraph.polyomino.org.uk> <20180319015122.j5tzslkdcnvampoh@var.youpi.perso.aquilenet.fr> <20180402001003.3u5n2p5pdmv4hos5@var.youpi.perso.aquilenet.fr>
On Mon, 2 Apr 2018, Samuel Thibault wrote:
> - header standard conformity issues: These will be hard to fix.
What are the issues here?
> - elf/check-localplt: There will always be PLTs to libhurd/machuser.so
> anyway.
If a library has *local* PLT entries - PLT entries for within-library
calls to other functions in that shared library - that are hard to fix to
use hidden aliases, it's expected that the localplt.data files will list
those as expected (with a "?" if the PLT entry may or may not be present
depending on compiler version etc., as is the case for some configurations
where functions get exported from both libgcc and glibc).
> - elf/check-execstack: We have nested functions which make the stack
> executable indeed.
That's pointers to nested functions involving creation of trampolines?
Do those nested functions actually improve the code or would it be cleaner
(have cleaner internal interfaces etc.) without them? Do all libraries
have these or only some?
> - check-abi-libmachuser, check-abi-libhurduser: These actually depend on
> .defs files in gnumach and hurd, so we can't really define ABI files.
Depend in what way? Are you saying they export different symbols
depending on the versions of gnumach and hurd glibc is built with? How
are symbol versions for such extra symbols determined - based on gnumach
and hurd versions instead of glibc versions?
It's clearly desirable to be able to make sure that old symbol versions
don't change. But if the contents of those versions are determined by
gnumach and hurd, maybe those packages need to install ABI baselines for
the glibc tests (or something like that).
The nearest analogue I see in glibc for systems using the Linux kernel
(without more information on how the gnumach/hurd dependency works) is the
syscall lists - where we have a list in glibc of all possible syscall
names (sysdeps/unix/sysv/linux/syscall-names.list), and a test will fail
if the kernel has additional syscalls and is not newer than the version
listed in that list (so using a different kernel version does not result
in test failures, but the test is fully effective if the listed kernel
version or an older kernel version is used).
--
Joseph S. Myers
joseph@codesourcery.com