[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upstreaming the glibc Hurd port

From: Joseph Myers
Subject: Re: Upstreaming the glibc Hurd port
Date: Tue, 3 Apr 2018 00:10:30 +0000
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]