mesa3d-dev

[Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Brian P. <br...@va...>]

Chaskiel M Grundman wrote:
> 
> Around line 90 of xc/extras/Mesa/src/X86/common_x86.c
> #if defined(__linux__) && defined(_POSIX_SOURCE)
> [...]
> static void sigfpe_handler( int signal, struct sigcontext sc )
> {
>    message( "SIGFPE, " );
> 
>    if ( sc.fpstate->magic != 0xffff ) {
> 
> fpstate.magic is not defined in asm/sigcontext.h on my RedHat 6.2 box
> (which has a stock 2.2.19 kernel, not the redhat one). It is defined in
> the linux 2.4.5 asm/sigcontext.h, and I'm assuming the reason this is
> working for most people is that glibc 2.2's bits/sigcontext.h defines
> these things itself rather than deferring to the kernel headers.
> Something ought to be done about this, I think.
> 
> For my own purposes, I'm just going to disable SSE support entirely...


If anyone knows a solution to this I'd like to hear it.

-Brian

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > If anyone knows a solution to this I'd like to hear it.

 Sometime ago I submitted a patch for this (#403332).  The comment
 reads:

 | If the use of KATMAI instructions is enabled, on linux it's necessary
 | to have recent kernel headers installed (these are coupled to the C
 | library, so suggesting to place/change a link in /usr/src/ is not
 | advisable). There are two options for it's detection at compile time,
 | one is using LINUX_KERNEL_VERSION, what this patch does, the other is
 | checking for X86_FXSR_MAGIC to be defined. I'm sure Gareth can make a
 | recommendation as to which is better. With either of them, I think
 | it's important to provide the user with an error that at least
 | suggests a course of action (the current one goes along the lines of
 | "magic is not a member of structure sigcontext", IIRC)

 | The patch uses 2.4.0 as a reference point, I'm not really sure when
 | the SSE support was introduced in the kernel, but it's not on the
 | 2.2.18 I looked at.

 The patch, which is not on SF (weird) is basically:

Index: extras/Mesa/src/X86/common_x86.c
===================================================================
RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86.c,v
retrieving revision 1.10
diff -u -r1.10 common_x86.c
--- extras/Mesa/src/X86/common_x86.c    2001/02/12 20:42:42     1.10
+++ extras/Mesa/src/X86/common_x86.c    2001/06/05 15:22:50
@@ -88,6 +88,11 @@
 extern void gl_test_os_katmai_exception_support( void );
 
 #if defined(__linux__) && defined(_POSIX_SOURCE)
+#include <linux/version.h>
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
+#error "linux headers older than 2.4.0 don't provide support for SSE."
+#endif
+
 static void sigill_handler( int signal, struct sigcontext sc )
 {
    message( "SIGILL, " );

 Granted, it's not the best solution, but it's at least an useful error.
 Some conditionals on the configuration files would do it, too.
 (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
 kernel headers to compile this.

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Brian P. <br...@va...>]

"Marcelo E. Magallon" wrote:
> 
> >> Brian Paul <br...@va...> writes:
> 
>  > If anyone knows a solution to this I'd like to hear it.
> 
>  Sometime ago I submitted a patch for this (#403332).  The comment
>  reads:
> 
>  | If the use of KATMAI instructions is enabled, on linux it's necessary
>  | to have recent kernel headers installed (these are coupled to the C
>  | library, so suggesting to place/change a link in /usr/src/ is not
>  | advisable). There are two options for it's detection at compile time,
>  | one is using LINUX_KERNEL_VERSION, what this patch does, the other is
>  | checking for X86_FXSR_MAGIC to be defined. I'm sure Gareth can make a
>  | recommendation as to which is better. With either of them, I think
>  | it's important to provide the user with an error that at least
>  | suggests a course of action (the current one goes along the lines of
>  | "magic is not a member of structure sigcontext", IIRC)
> 
>  | The patch uses 2.4.0 as a reference point, I'm not really sure when
>  | the SSE support was introduced in the kernel, but it's not on the
>  | 2.2.18 I looked at.
> 
>  The patch, which is not on SF (weird) is basically:
> 
> Index: extras/Mesa/src/X86/common_x86.c
> ===================================================================
> RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86.c,v
> retrieving revision 1.10
> diff -u -r1.10 common_x86.c
> --- extras/Mesa/src/X86/common_x86.c    2001/02/12 20:42:42     1.10
> +++ extras/Mesa/src/X86/common_x86.c    2001/06/05 15:22:50
> @@ -88,6 +88,11 @@
>  extern void gl_test_os_katmai_exception_support( void );
> 
>  #if defined(__linux__) && defined(_POSIX_SOURCE)
> +#include <linux/version.h>
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
> +#error "linux headers older than 2.4.0 don't provide support for SSE."
> +#endif
> +
>  static void sigill_handler( int signal, struct sigcontext sc )
>  {
>     message( "SIGILL, " );
> 
>  Granted, it's not the best solution, but it's at least an useful error.
>  Some conditionals on the configuration files would do it, too.
>  (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
>  kernel headers to compile this.


I'd like to see a solution that doesn't interupt compilation.  That
is, if we can't use SSE at compile time, it should just be disabled,
perhaps with a warning.

The trick is there was a patch to Linux 2.2.x that added SSE so just
testing for kernel >= 2.4.0 isn't enough.  Does the presense of
X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

-Brian

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > The trick is there was a patch to Linux 2.2.x that added SSE so just
 > testing for kernel >= 2.4.0 isn't enough.  Does the presense of
 > X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

 Looking at the patch (2.4.0-test2), yes.  magic and X86_FXSR_MAGIC
 where introduced at the same time.

 I agree with you, stopping in the middle of the compilation isn't nice.
 The problem is you can't run something while generating the Makefiles
 from the Imakefiles, can you?  You just need to check that:

#include <signal.h>

#if defined(SSE_CHECK) && !defined(X86_FXSR_MAGIC)
#error "X86_FXSR_MAGIC not defined"
#endif

 doesn't produce an error.

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Mike A. H. <mh...@re...>]

On Tue, 5 Jun 2001, Brian Paul wrote:

>>  Granted, it's not the best solution, but it's at least an useful error.
>>  Some conditionals on the configuration files would do it, too.
>>  (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
>>  kernel headers to compile this.
>
>
>I'd like to see a solution that doesn't interupt compilation.  That
>is, if we can't use SSE at compile time, it should just be disabled,
>perhaps with a warning.

Then in order to use SSE on a machine at runtime, one must have
an SSE capable machine to build on?  I don't like the sound of
that, even if my box has SSE.  IMHO, the build host should be
independant of the runtime host.

Perhaps I am misunderstanding the above comments?



----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile4.1 on RedHat 6.2)

[Brian P. <br...@va...>]

"Mike A. Harris" wrote:
> 
> On Tue, 5 Jun 2001, Brian Paul wrote:
> 
> >>  Granted, it's not the best solution, but it's at least an useful error.
> >>  Some conditionals on the configuration files would do it, too.
> >>  (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
> >>  kernel headers to compile this.
> >
> >
> >I'd like to see a solution that doesn't interupt compilation.  That
> >is, if we can't use SSE at compile time, it should just be disabled,
> >perhaps with a warning.
> 
> Then in order to use SSE on a machine at runtime, one must have
> an SSE capable machine to build on?  I don't like the sound of
> that, even if my box has SSE.  IMHO, the build host should be
> independant of the runtime host.
> 
> Perhaps I am misunderstanding the above comments?

Perhaps so.  At runtime, the Mesa code tries to execute some SSE
instructions and checks if it works or not.  It might fail because
there's no kernel support or you're using a CPU without SSE
instructions.  This is done with an exception handler.

Now at compile time we need at least a certain version of the system
headers in order to compile the exception handler code.
If we don't have the right headers, we can't compile the code.  I'm
just saying that I'd rather the compilation continued without SSE
capability rather than bomb out.

If you've got the right headers but compiling on a non-SSE CPU you
can certainly compile in the SSE support.  You just won't be able to
use it on that system.

-Brian

Re: [Mesa3d-dev] Re: mesa assuming glibc 2.2? (Cannot compile4.1 on RedHat 6.2)

[Mike A. H. <mh...@re...>]

On Tue, 5 Jun 2001, Brian Paul wrote:

>> Then in order to use SSE on a machine at runtime, one must have
>> an SSE capable machine to build on?  I don't like the sound of
>> that, even if my box has SSE.  IMHO, the build host should be
>> independant of the runtime host.
>>
>> Perhaps I am misunderstanding the above comments?
>
>Perhaps so.  At runtime, the Mesa code tries to execute some SSE
>instructions and checks if it works or not.  It might fail because
>there's no kernel support or you're using a CPU without SSE
>instructions.  This is done with an exception handler.
>
>Now at compile time we need at least a certain version of the system
>headers in order to compile the exception handler code.
>If we don't have the right headers, we can't compile the code.  I'm
>just saying that I'd rather the compilation continued without SSE
>capability rather than bomb out.
>
>If you've got the right headers but compiling on a non-SSE CPU you
>can certainly compile in the SSE support.  You just won't be able to
>use it on that system.

Ok, that all makes sense then.  An autoconf check ala:

checking if proper headers for SSE support exist... no

That would be ok I suppose, as the build environment really
should match the end-use environment IMHO for stable packaging,
however the CPU may differ at runtime, so the above should be ok.



----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> "Mike A. Harris" <mh...@re...> writes:

 > Then in order to use SSE on a machine at runtime, one must have
 > an SSE capable machine to build on?  I don't like the sound of
 > that, even if my box has SSE.  IMHO, the build host should be
 > independant of the runtime host.

 No, you must have a machine with the correct kernel headers, that is,
 with a glibc that provides the correct headers.

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[David D. <da...@XF...>]

On Tue, Jun 05, 2001 at 09:56:44AM -0600, Brian Paul wrote:
>"Marcelo E. Magallon" wrote:
>> 
>> >> Brian Paul <br...@va...> writes:
>> 
>>  > If anyone knows a solution to this I'd like to hear it.
>> 
>>  Sometime ago I submitted a patch for this (#403332).  The comment
>>  reads:
>> 
>>  | If the use of KATMAI instructions is enabled, on linux it's necessary
>>  | to have recent kernel headers installed (these are coupled to the C
>>  | library, so suggesting to place/change a link in /usr/src/ is not
>>  | advisable). There are two options for it's detection at compile time,
>>  | one is using LINUX_KERNEL_VERSION, what this patch does, the other is
>>  | checking for X86_FXSR_MAGIC to be defined. I'm sure Gareth can make a
>>  | recommendation as to which is better. With either of them, I think
>>  | it's important to provide the user with an error that at least
>>  | suggests a course of action (the current one goes along the lines of
>>  | "magic is not a member of structure sigcontext", IIRC)
>> 
>>  | The patch uses 2.4.0 as a reference point, I'm not really sure when
>>  | the SSE support was introduced in the kernel, but it's not on the
>>  | 2.2.18 I looked at.
>> 
>>  The patch, which is not on SF (weird) is basically:
>> 
>> Index: extras/Mesa/src/X86/common_x86.c
>> ===================================================================
>> RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/X86/common_x86.c,v
>> retrieving revision 1.10
>> diff -u -r1.10 common_x86.c
>> --- extras/Mesa/src/X86/common_x86.c    2001/02/12 20:42:42     1.10
>> +++ extras/Mesa/src/X86/common_x86.c    2001/06/05 15:22:50
>> @@ -88,6 +88,11 @@
>>  extern void gl_test_os_katmai_exception_support( void );
>> 
>>  #if defined(__linux__) && defined(_POSIX_SOURCE)
>> +#include <linux/version.h>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
>> +#error "linux headers older than 2.4.0 don't provide support for SSE."
>> +#endif
>> +
>>  static void sigill_handler( int signal, struct sigcontext sc )
>>  {
>>     message( "SIGILL, " );
>> 
>>  Granted, it's not the best solution, but it's at least an useful error.
>>  Some conditionals on the configuration files would do it, too.
>>  (HAVE_LINUX_2_4_HEADERS, Imakefile style).  The point is, you need 2.4
>>  kernel headers to compile this.
>
>
>I'd like to see a solution that doesn't interupt compilation.  That
>is, if we can't use SSE at compile time, it should just be disabled,
>perhaps with a warning.
>
>The trick is there was a patch to Linux 2.2.x that added SSE so just
>testing for kernel >= 2.4.0 isn't enough.  Does the presense of
>X86_FXSR_MAGIC ensure that the _fpstate.magic field exists?

For builds within XFree86, linux.cf already has the kernel version check:

#ifndef HasKatmaiSupport
#  ifdef i386Architecture
#    if OSMajorVersion > 2 || (OSMajorVersion == 2 && OSMinorVersion >= 4)
#      define HasKatmaiSupport          YES
#    else
#      define HasKatmaiSupport          NO
#    endif
#  else
#    define HasKatmaiSupport            NO
#  endif
#endif

It assumes that the kernel headers will be found for the build though.

David
--
David Dawes                                      Email: da...@XF...
Founder/President, The XFree86 Project, Inc      Phone: +1 510 687 6857
http://www.xfree86.org/

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Gareth H. <gar...@ac...>]

Brian Paul wrote:
> 
> Chaskiel M Grundman wrote:
> >
> > Around line 90 of xc/extras/Mesa/src/X86/common_x86.c
> > #if defined(__linux__) && defined(_POSIX_SOURCE)
> > [...]
> > static void sigfpe_handler( int signal, struct sigcontext sc )
> > {
> >    message( "SIGFPE, " );
> >
> >    if ( sc.fpstate->magic != 0xffff ) {
> >
> > fpstate.magic is not defined in asm/sigcontext.h on my RedHat 6.2 box
> > (which has a stock 2.2.19 kernel, not the redhat one). It is defined in
> > the linux 2.4.5 asm/sigcontext.h, and I'm assuming the reason this is
> > working for most people is that glibc 2.2's bits/sigcontext.h defines
> > these things itself rather than deferring to the kernel headers.
> > Something ought to be done about this, I think.
> >
> > For my own purposes, I'm just going to disable SSE support entirely...
> 
> If anyone knows a solution to this I'd like to hear it.

It's a rather nasty problem.  The solutions you proposed seems to be
okay, but I'll dig around and get back to you.  There may be other
issues that I've forgotten about, which I why I didn't just test for the
kernel version when I did that work.

-- Gareth

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Sven M. H. <pe...@gm...>]

On Tue, Jun 05, 2001 at 08:47:07AM -0600, Brian Paul wrote:
> Chaskiel M Grundman wrote:
> > 
> > Around line 90 of xc/extras/Mesa/src/X86/common_x86.c
> > #if defined(__linux__) && defined(_POSIX_SOURCE)
> > [...]
> > static void sigfpe_handler( int signal, struct sigcontext sc )
> > {
> >    message( "SIGFPE, " );
> > 
> >    if ( sc.fpstate->magic != 0xffff ) {
> > 
> > fpstate.magic is not defined in asm/sigcontext.h on my RedHat 6.2 box
> > (which has a stock 2.2.19 kernel, not the redhat one). It is defined in
> > the linux 2.4.5 asm/sigcontext.h, and I'm assuming the reason this is
> > working for most people is that glibc 2.2's bits/sigcontext.h defines
> > these things itself rather than deferring to the kernel headers.
> > Something ought to be done about this, I think.
> > 
> > For my own purposes, I'm just going to disable SSE support entirely...
> 
> 
> If anyone knows a solution to this I'd like to hear it.

As far as autoconf is concerned, a simple test case will find out whether
fpstate.magic is defined. The code would use an #ifdef. The usual way, really.

Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > As far as autoconf is concerned, a simple test case will find out
 > whether fpstate.magic is defined. The code would use an #ifdef. The
 > usual way, really.

 Yes, the problem is doing this with Imakefiles.  You depend on whatever
 the 

 I have looked a bit more into this...

 The solution Brian is looking for looks like:

#include <signal.h>
/* ... */
#if defined(USE_KATMAI_ASM) && defined(X86_FXSR_MAGIC)
/* ... */
#endif

 this compiles the SSE support only if the glibc kernel headers are 2.4
 headers (or patched 2.2 ones).  I don't like it, it's ugly.

 The proper solution is teaching config/imake/imake.c about
 DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
 X86_FXSR_MAGIC is defined, and NO in other case.  Massage other files
 to use this.  Of course this doesn't solve the case where the user
 intentionally sets HasKatmaiSupport to YES but doesn't have the correct
 headers.  With the imake system you can't solve that.

 This is Linux specific, I have no idea how to handle this in other X86
 OS.  Anyone with a clue?

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Marcelo E. M. <mar...@bi...>]

>> "Marcelo E. Magallon" <mar...@bi...> writes:

 >  The proper solution is teaching config/imake/imake.c about
 >  DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
 >  X86_FXSR_MAGIC is defined, and NO in other case.  Massage other
 >  files to use this.  Of course this doesn't solve the case where the
 >  user intentionally sets HasKatmaiSupport to YES but doesn't have the
 >  correct headers.  With the imake system you can't solve that.

 I just uploaded a patch that does this.  (#403332)

-- 
Marcelo

Re: [Mesa3d-dev] Re: [Xpert]mesa assuming glibc 2.2? (Cannot compile 4.1 on RedHat 6.2)

[Brian P. <br...@va...>]

"Marcelo E. Magallon" wrote:
> 
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > As far as autoconf is concerned, a simple test case will find out
>  > whether fpstate.magic is defined. The code would use an #ifdef. The
>  > usual way, really.
> 
>  Yes, the problem is doing this with Imakefiles.  You depend on whatever
>  the
> 
>  I have looked a bit more into this...
> 
>  The solution Brian is looking for looks like:
> 
> #include <signal.h>
> /* ... */
> #if defined(USE_KATMAI_ASM) && defined(X86_FXSR_MAGIC)
> /* ... */
> #endif
> 
>  this compiles the SSE support only if the glibc kernel headers are 2.4
>  headers (or patched 2.2 ones).  I don't like it, it's ugly.

I've committed this solution (basically).  I don't think it's ugly.


>  The proper solution is teaching config/imake/imake.c about
>  DefaultHasKatmaiSupport.  Include signal.h and define this as YES if
>  X86_FXSR_MAGIC is defined, and NO in other case.  Massage other files
>  to use this.  Of course this doesn't solve the case where the user
>  intentionally sets HasKatmaiSupport to YES but doesn't have the correct
>  headers.  With the imake system you can't solve that.
> 
>  This is Linux specific, I have no idea how to handle this in other X86
>  OS.  Anyone with a clue?

I think simply patching the source file with the test for X86_FXSR_MAGIC
is sufficient.

-Brian