This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Upstreaming the glibc Hurd port
- From: Samuel Thibault <samuel dot thibault at gnu dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- 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 17:50:17 +0200
- Subject: Re: Upstreaming the glibc Hurd port
- References: <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> <alpine.DEB.2.20.1804021407480.16203@digraph.polyomino.org.uk>
Joseph Myers, on lun. 02 avril 2018 14:17:38 +0000, wrote:
> On Mon, 2 Apr 2018, Samuel Thibault wrote:
>
> > - header standard conformity issues: These will be hard to fix.
>
> What are the issues here?
Some of these are small, like ./bits/types/sigevent_t.h's
sigev_notify_attributes not being pthread_attr_t*
Others need some work, like the missing SA_SIGINFO, for which we have
patches which need polishing and committing.
Others need implementing, like SA_NOCLDWAIT.
Others just need defining, like IUCLC, IXANY, etc.
There are a few remaining namespace issues due to missing __ marking or
spurious #includes.
So those, we can fix them.
Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's
l_type/l_whence being int instead of short.
There is also sys/un.h which defines a sun_len field, which IIRC is to
be expected on BSD systems, but not defined in Posix?
Also, ioctl takes (int, unsigned long int, ...) but
./conform/XPG42/stropts.h/conform.out wants (int, int, ...)?
> > - elf/check-localplt: There will always be PLTs to libhurd/machuser.so
> > anyway.
>
> If a library has *local* PLT entries -
Ah. I got confused by the presence of __vm_allocate which is an RPC,
but we actually have a non-RPC version inside libc.so itself. There are
a hundred of them mostly in libc.so, ld.so, libpthread.so
> 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
Ok.
> > - elf/check-execstack: We have nested functions which make the stack
> > executable indeed.
>
> That's pointers to nested functions involving creation of trampolines?
Yes.
> Do those nested functions actually improve the code
Yes. There are notably callbacks whose parameters don't permit to get
the context parameters etc.
> Do all libraries have these or only some?
Only libc.so, ld.so and libpthread.so have them.
> > - 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?
That is it, yes.
> How are symbol versions for such extra symbols determined - based on
> gnumach and hurd versions instead of glibc versions?
That was not actually settled, but I guess it should be gnumach and hurd
versions.
> maybe those packages need to install ABI baselines for the glibc tests
> (or something like that).
Indeed.
Samuel