Re: Upstreaming the glibc Hurd port

[Samuel Thibault <samuel.thibault@gnu.org>]

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