Re: Include coherency problem, sigaction and otherwise

Re: Include coherency problem, sigaction and otherwise

[Kevin D. Kissell]

William J. Earl writes:
>Kevin D. Kissell writes:
...
> > I have the impresson that the /usr/include stuff in the 
> > "Hard Hat" distribution for MIPS is keyed to a 2.0.x kernel, 
> > and that an update of /usr/include (as opposed to a downgrade 
> > of the kernel headers) may be in order.
...
>
>      As near as I can tell, at least for glibc-2.1.1-7, there
>is not machine-dependent <bits/sigaction.h> for mips, so the
>generic one is used, and the definitions are incompatible with the
>MIPS ABI.  The Linux kernel, on the other hand, is compatible with the
>MIPS ABI.  The cure is to supply a MIPS-specific <bits/sigaction.h>.

It's worse than that - the "Hard Hat" 5.1 distribution that serves
as the reference userland for most SGI/MIPS/Linux platforms
doesn't even have a /usr/include/bits directory, which seems
to have been a more recent invention.

            Regards,

            Kevin K.

Re: Include coherency problem, sigaction and otherwise

[Ralf Baechle]

On Fri, Mar 17, 2000 at 07:28:38PM +0100, Kevin D. Kissell wrote:

> > > I have the impresson that the /usr/include stuff in the 
> > > "Hard Hat" distribution for MIPS is keyed to a 2.0.x kernel, 
> > > and that an update of /usr/include (as opposed to a downgrade 
> > > of the kernel headers) may be in order.
> ...
> >
> >      As near as I can tell, at least for glibc-2.1.1-7, there
> >is not machine-dependent <bits/sigaction.h> for mips, so the
> >generic one is used, and the definitions are incompatible with the
> >MIPS ABI.  The Linux kernel, on the other hand, is compatible with the
> >MIPS ABI.  The cure is to supply a MIPS-specific <bits/sigaction.h>.
> 
> It's worse than that - the "Hard Hat" 5.1 distribution that serves
> as the reference userland for most SGI/MIPS/Linux platforms
> doesn't even have a /usr/include/bits directory, which seems
> to have been a more recent invention.

The whole inconsistence was a stupid accident.  Since apparently only very
little software was affected negativly (read: no known problems) we didn't
try to come up with some genious compatibility hacks but just fixed the
definitions the hard way.  Current glibc snapshots and Linux kernels have
been fixed to use the same definitions.  If not, mail me a brown paperbag.

The bits/ subdirectory was introduced for glibc 2.1.

  Ralf

Re: Include coherency problem, sigaction and otherwise

[William J. Earl]

Ralf Baechle writes:
...
 > The bits/ subdirectory was introduced for glibc 2.1.

    The bits/ subdirectory is present in 2.1, but at least 2.1.1-7 does
not have a bits/sigaction.h for MIPS in the source, so the generic 
one is used, and that is inconsistent with the kernel.  Which source
for glibc has a MIPS bits/sigaction.h?

Re: Include coherency problem, sigaction and otherwise

[Ralf Baechle]

On Fri, Mar 17, 2000 at 08:41:24PM -0800, William J. Earl wrote:

>  > The bits/ subdirectory was introduced for glibc 2.1.
> 
>     The bits/ subdirectory is present in 2.1, but at least 2.1.1-7 does
> not have a bits/sigaction.h for MIPS in the source, so the generic 
> one is used, and that is inconsistent with the kernel.

2.1 isn't supposed to be usable or even compilable for MIPS thanks to the
infamous linker problems.  Details on request.

> Which source for glibc has a MIPS bits/sigaction.h?

The latest Cygnus CVS development version has this and many other buglets
corrected mostly thanks to Andreas Jaeger who did start integrating my
old 2.0 port with the GNU sources and fix a ton of such buglets.

  Ralf

Re: Include coherency problem, sigaction and otherwise

[Kevin D. Kissell]

>> Certainly the hardhat-sgi-5.1-tar.gz archive on oss.sgi.com is out of sync
>> with any MIPS/Linux kernel sources of which I am aware.  The most recent
>> version of glibc 2.0 for MIPS that I have been able to find is 2.0.7, and it
>> too seems to be out of synch.  Which version of glibc has been fixed,
>> and where can I download it?   Which userland distribution is built with
>> the consistent glibc?
>
>Definately no entire distribution, I'm also not sure if I actually did
>publish a fixed libc due to another binutils related issue.  I'm about to
>jump into a plane but could you take a look at
>pub/linux/mips/redhat/manhattan/RedHat/RPMS/glibc-2.0.6-4.mipseb.rpm
>from oss?
>
>  Ralf  (Up, up and away ...)

I checked.  2.0.6-4 seems to be the same version as is in
the hardhat-sgi-5.1-tar.gz archive, and as such is broken.

Hope you're having a good flight!

            Kevin K.

Re: Include coherency problem, sigaction and otherwise

[Kevin D. Kissell]

>> > > I have the impresson that the /usr/include stuff in the
>> > > "Hard Hat" distribution for MIPS is keyed to a 2.0.x kernel,
>> > > and that an update of /usr/include (as opposed to a downgrade
>> > > of the kernel headers) may be in order.
>> ...
>> >      As near as I can tell, at least for glibc-2.1.1-7, there
>> >is not machine-dependent <bits/sigaction.h> for mips, so the
>> >generic one is used, and the definitions are incompatible with the
>> >MIPS ABI.  The Linux kernel, on the other hand, is compatible with the
>> >MIPS ABI.  The cure is to supply a MIPS-specific <bits/sigaction.h>.
>>
>> It's worse than that - the "Hard Hat" 5.1 distribution that serves
>> as the reference userland for most SGI/MIPS/Linux platforms
>> doesn't even have a /usr/include/bits directory, which seems
>> to have been a more recent invention.
>
>The whole inconsistence was a stupid accident.  Since apparently only very
>little software was affected negativly (read: no known problems)  we didn't
>try to come up with some genious compatibility hacks but just fixed the
>definitions the hard way.

Having two independent sets of include files between kernel and userland
is always a bad idea, but is not *necessarily* broken, and sometimes
cannot be avoided.   The problem is not that the definitions are seperately
wired, but that they are incompatible - the risk one takes when one creates
multiple independent definitions.

>                                     Current glibc snapshots and Linuxkernels
have
>been fixed to use the same definitions.  If not, mail me a brown paperbag.

Certainly the hardhat-sgi-5.1-tar.gz archive on oss.sgi.com is out of sync
with any MIPS/Linux kernel sources of which I am aware.  The most recent
version of glibc 2.0 for MIPS that I have been able to find is 2.0.7, and it
too seems to be out of synch.  Which version of glibc has been fixed,
and where can I download it?   Which userland distribution is built with
the consistent glibc?

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

Re: Include coherency problem, sigaction and otherwise

[Ralf Baechle]

On Sat, Mar 18, 2000 at 12:57:29PM +0100, Kevin D. Kissell wrote:

> Having two independent sets of include files between kernel and userland
> is always a bad idea, but is not *necessarily* broken, and sometimes
> cannot be avoided.   The problem is not that the definitions are seperately
> wired, but that they are incompatible - the risk one takes when one creates
> multiple independent definitions.

The problem before that was that using the kernel headers for userland was
a serious problem.

> >                                     Current glibc snapshots and Linuxkernels
> have
> >been fixed to use the same definitions.  If not, mail me a brown paperbag.
> 
> Certainly the hardhat-sgi-5.1-tar.gz archive on oss.sgi.com is out of sync
> with any MIPS/Linux kernel sources of which I am aware.  The most recent
> version of glibc 2.0 for MIPS that I have been able to find is 2.0.7, and it
> too seems to be out of synch.  Which version of glibc has been fixed,
> and where can I download it?   Which userland distribution is built with
> the consistent glibc?

Definately no entire distribution, I'm also not sure if I actually did
publish a fixed libc due to another binutils related issue.  I'm about to
jump into a plane but could you take a look at
pub/linux/mips/redhat/manhattan/RedHat/RPMS/glibc-2.0.6-4.mipseb.rpm
from oss?

  Ralf  (Up, up and away ...)

Re: Include coherency problem, sigaction and otherwise

[William J. Earl]

Kevin D. Kissell writes:
...
 > >The whole inconsistence was a stupid accident.  Since apparently only very
 > >little software was affected negativly (read: no known problems)  we didn't
 > >try to come up with some genious compatibility hacks but just fixed the
 > >definitions the hard way.
 > 
 > Having two independent sets of include files between kernel and userland
 > is always a bad idea, but is not *necessarily* broken, and sometimes
 > cannot be avoided.   The problem is not that the definitions are seperately
 > wired, but that they are incompatible - the risk one takes when one creates
 > multiple independent definitions.

      In this case the definitions are supposed to match the MIPS ABI.
That the glibc definitions (at least as of 2.1.1) do not is just a glibc bug.
This is no different that having Linux and FreeBSD header files for some
I/O controller, with one of them having incorrect values for some field
definitions.  The one which does not match the standard (the ABI or the
I/O controller hardware) is simply wrong.

     Since glibc is shared among a great many operating systems, it really
needs to be self-contained in regard to the C and POSIX and UNIX98 standards.

Include coherency problem, sigaction and otherwise

[Kevin D. Kissell]

Invesitgating some non-fatal but odd behaviour, we
have traced it to the fact that the defintions of various
sigaction flags are defined for MIPS/Linux user code
in /usr/include/sigaction.h, but defined for the kernel in
/usr/include/asm/signal.h, and that the two definitions
are not consistent.  Does anyone know how this
came about?  

I have the impresson that the /usr/include stuff in the 
"Hard Hat" distribution for MIPS is keyed to a 2.0.x kernel, 
and that an update of /usr/include (as opposed to a downgrade 
of the kernel headers) may be in order.    Frankly, I don't like 
the fact that the user and kernel includes don't pull everything 
out of common files in include/linux and include/asm - I suppose 
it must have been to reduce the number of compilations
that depend on kernel includes - but I don't see that
we can do much about that from here in MIPS-land.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

Re: Include coherency problem, sigaction and otherwise

[William J. Earl]

Kevin D. Kissell writes:
 > Invesitgating some non-fatal but odd behaviour, we
 > have traced it to the fact that the defintions of various
 > sigaction flags are defined for MIPS/Linux user code
 > in /usr/include/sigaction.h, but defined for the kernel in
 > /usr/include/asm/signal.h, and that the two definitions
 > are not consistent.  Does anyone know how this
 > came about?  
 > 
 > I have the impresson that the /usr/include stuff in the 
 > "Hard Hat" distribution for MIPS is keyed to a 2.0.x kernel, 
 > and that an update of /usr/include (as opposed to a downgrade 
 > of the kernel headers) may be in order.    Frankly, I don't like 
 > the fact that the user and kernel includes don't pull everything 
 > out of common files in include/linux and include/asm - I suppose 
 > it must have been to reduce the number of compilations
 > that depend on kernel includes - but I don't see that
 > we can do much about that from here in MIPS-land.

      As near as I can tell, at least for glibc-2.1.1-7, there
is not machine-dependent <bits/sigaction.h> for mips, so the
generic one is used, and the definitions are incompatible with the
MIPS ABI.  The Linux kernel, on the other hand, is compatible with the
MIPS ABI.  The cure is to supply a MIPS-specific <bits/sigaction.h>.
In particular, we need for mips:

/* Bits in `sa_flags'.  */
#if defined __USE_UNIX98 || defined __USE_MISC
# define SA_ONSTACK	0x0001	/* Take signal on signal stack.  */
# define SA_RESTART	0x0004	/* Restart syscall on signal return.  */
#endif
#define	SA_NOCLDSTOP	0x20000	/* Don't send SIGCHLD when children stop.  */

instead of the generic:

/* Bits in `sa_flags'.  */
#if defined __USE_UNIX98 || defined __USE_MISC
# define SA_ONSTACK	0x0001	/* Take signal on signal stack.  */
# define SA_RESTART	0x0002	/* Restart syscall on signal return.  */
#endif
#define	SA_NOCLDSTOP	0x0008	/* Don't send SIGCHLD when children stop.  */

This is just a symptom of the somewhat weak MIPS support in glibc and
binutils.

The generic source file is 

    glibc/sysdeps/generic/bits/sigaction.h

and the MIPS source file would be

    glibc/sysdeps/mips/bits/sigaction.h

THere are probably other incompatibilities to be weeded out.