Re: Upstreaming the glibc Hurd port

[Joseph Myers]

On Mon, 2 Apr 2018, Samuel Thibault wrote:

> Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's
> l_type/l_whence being int instead of short.

Where something is problematic to fix, because a fix would break the ABI 
or needs some external feature, there is an xfail mechanism internal to 
the conform tests.  It involves a bug being filed in Bugzilla for the 
issue in question, an addition to conformtest-xfail-conds (conditional on 
ifeq ($(subdir),conform)) in an appropriate sysdeps Makefile, with a 
comment referencing the bug, and xfail[cond]- on the relevant expectation 
in the relevant -data file, again with a comment referencing the bug.  
For example:

// Bug 17786: st_dev has wrong type.
xfail[mips-o32-linux]-element {struct stat} dev_t st_dev

Before doing any such XFAILing, you should check that the expectation is 
actually backed up by the relevant standard and that a fix really does 
need an ABI change or a new feature.  Also, this XFAIL mechanism can only 
be used for positive expectations that are failing - it can't be used for 
cases where the header violates the expected namespace.

> 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?

Well, in fact POSIX reserves sun_* for sys/un.h (note the reservations are 
in a separate part of the standard from the main definitions of header 
contents), so there's a bug in the expectations not allowing for it.  This 
illustrates the need for checking such failures against the standards to 
see where the bug is.

> Also, ioctl takes (int, unsigned long int, ...) but
> ./conform/XPG42/stropts.h/conform.out wants (int, int, ...)?

That's already generically XFAILed with reference to bug 14362.

> > 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.

Then maybe some mechanism is needed for sysdeps Makefiles to define 
libraries expected to have executable stacks.

-- 
Joseph S. Myers
joseph@codesourcery.com