Bug#410474: More info

2007-04-05 Thread Lennart Sorensen
I managed to come up with a much simpler solution and hence a much
simpler patch, which is not linux specific and does not require /proc or
any other file parsing.

It turns out the upstream fix to mysql was on the right track, but must
have been working on a BSD system or at least something similar.  On BSD
setjmp saves signal context.  On SysV (and linux too it seems), it does
not.  This causes it to break.  By switching the code to using sigsetjmp
and siglongjmp instead, and passing the argument to explicitly save the
signal context, the problem disappears and my 486 works great.  I
verified with some debuging that it does in fact correctly detect that
my 486 does not have cpuid, and that my athlon does have cpuid.

This should be applied to mysql 5.whichever to fix 486 (and other
cpuid-less cpu) support in Etch, and Sid too for that matter.  After all
Etch is supposed to support 486s and without this fix, it does not in
many cases.  It is also a very simple change and should not cause any
new problems.  I would think that this qualifies as release critical.

--
Len Sorensen

--- mysql-dfsg-5.0-5.0.36.ori/extra/yassl/taocrypt/src/misc.cpp 2007-02-20 
12:49:38.0 -0500
+++ mysql-dfsg-5.0-5.0.36/extra/yassl/taocrypt/src/misc.cpp 2007-04-05 
12:29:34.0 -0400
@@ -167,10 +167,10 @@
 #ifdef TAOCRYPT_X86ASM_AVAILABLE
 
 #ifndef _MSC_VER
-static jmp_buf s_env;
+static sigjmp_buf s_env;
 static void SigIllHandler(int)
 {
-longjmp(s_env, 1);
+siglongjmp(s_env, 1);
 }
 #endif
 
@@ -199,7 +199,7 @@
 return false;
 
 bool result = true;
-if (setjmp(s_env))
+if (sigsetjmp(s_env,1))
 result = false;
 else 
 __asm__ __volatile


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#410474: More info

2007-04-04 Thread Lennart Sorensen
I have a 486 DX2/66 (no cpuid instruction), which also get and illegal
instruction whenever anything tries to use the mysql libraries.  In my
case I saw it when trying to start proftpd after upgrading from sarge to
etch.  If I comment out the mysql modules in the proftpd config, the
problem goes away so it certainly matches with a mysql problem on this
cpu type.

So with current etch packages, mysql is still broken (version
5.0.32-7etch1).  I have not tried the 5.0.36 packages from sid yet to
see if that solves it.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#410474: More info

2007-04-04 Thread Lennart Sorensen
On Wed, Apr 04, 2007 at 05:48:22PM -0400, Lennart Sorensen wrote:
 I have a 486 DX2/66 (no cpuid instruction), which also get and illegal
 instruction whenever anything tries to use the mysql libraries.  In my
 case I saw it when trying to start proftpd after upgrading from sarge to
 etch.  If I comment out the mysql modules in the proftpd config, the
 problem goes away so it certainly matches with a mysql problem on this
 cpu type.
 
 So with current etch packages, mysql is still broken (version
 5.0.32-7etch1).  I have not tried the 5.0.36 packages from sid yet to
 see if that solves it.

I checked with 5.0.36 from unstable, and it too is broken.

It seems pretty bad if anything using libmysql on a system without cpuid
is automatically broken by upgrading to etch.

Anything I can do to help fix this before the release of Etch?

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#410474: More info

2007-04-04 Thread Lennart Sorensen
I looked at the cpuid code in yassl, and while it tries to safely check
for the cpuid instruction first, it does it in a broken way.

it currently sets up a signal handler to catch the illegal instruction
if it isn't supported, by using signal(), but unfortunately that is not
supported in multithreaded programs, which probably almost all libmysql
using programs are.  It would be MUCH safer to actually parse
/proc/cpuinfo to check if the cpuid instruction is listed there as
supported before trying to use it, and only then try to find out the
cpu type in the system.

Running the current yassl cpuid code without threads, works as expected.
Running it with threads causes the signal to go to the parent thread
rather than the one running cpuid (with the signal handler set), and the
main thread terminals with 'illegal instruction' which aborts the whole
program.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#410474: More info

2007-04-04 Thread Lennart Sorensen
Here is a patch that makes mysql run on my 486 without disabling use of
MMX, and such on other systems.

It isn't great yet, since it should really have some ifdef's for linux
only since it requires the linux specific /proc/cpuinfo, which of course
implies it requires /proc to be mounted.  On the other hand it is a much
safer (and thread safe too) way to check for cpuid presence before using
it.  This make php and proftpd run fine with mysql enabled on my 486.
The original way of handling cpuid missing is not thread safe, and since
mysql is supposed to be thread safe it just isn't a valid solution.  I
am not sure how one would do signal handling safely with threads.  If I
can figure that out, then that would probably be better than using
/proc/cpuinfo but at least there is potential for a solution.

Of course I imagine the same code that I am patching is used on bsd and
various other systems too, which I would have no clude how to fix.  But
at least with a little more work this could becaome a way to at least
maintain support for 486's on linux while still allowing the use of
newer instruction sets on most machines.

Some error checking on the file open and such might also be nice.  I may
see if I can clean it up a bit tomorrow.

--- mysql.ori/extra/yassl/taocrypt/src/misc.cpp 2007-02-20 12:49:38.0 
-0500
+++ mysql/extra/yassl/taocrypt/src/misc.cpp 2007-04-04 22:43:51.0 
-0400
@@ -21,7 +21,8 @@
 
 #include runtime.hpp
 #include misc.hpp
-
+#include stdio.h
+#include string.h
 
 #ifdef __GNUC__
 #include signal.h
@@ -174,6 +175,7 @@
 }
 #endif
 
+static bool have_cpu_id = false;
 
 bool HaveCpuId()
 {
@@ -192,27 +194,30 @@
 }
 return true;
 #else
-typedef void (*SigHandler)(int);
-
-SigHandler oldHandler = signal(SIGILL, SigIllHandler);
-if (oldHandler == SIG_ERR)
-return false;
+// Cache value to avoid doing this crap each call
+if(have_cpu_id) return true;
 
-bool result = true;
-if (setjmp(s_env))
-result = false;
-else 
-__asm__ __volatile
-(
-// save ebx in case -fPIC is being used
-push %%ebx; mov $0, %%eax; cpuid; pop %%ebx
-: 
-:
-: %eax, %ecx, %edx 
-);
-
-signal(SIGILL, oldHandler);
-return result;
+FILE *input;
+char *line = NULL;
+size_t linelength;
+
+input = fopen(/proc/cpuinfo,r);
+while(getline(line, linelength, input)  -1) {
+   if(0 == strncmp(line,cpuid level,11)) {
+   char *tmp = line;
+   tmp = strstr(tmp,:);
+   tmp++;
+   tmp++;
+   // cpuid level -1 means not supported.
+   if(*tmp == '-') {
+   have_cpu_id = false;
+   } else {
+   have_cpu_id = true;
+   }
+   return have_cpu_id;
+   }
+}
+return have_cpu_id;
 #endif
 }
 

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]