MySQL Bugs: #45131: Problems building on 32-bit linux

Bug #45131	Problems building on 32-bit linux
Submitted:	27 May 2009 13:55	Modified:	29 Jun 2009 0:36
Reporter:	Anders Karlsson	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.4.0	OS:	Linux
Assigned to:	Daniel Fischer	CPU Architecture:	Any

Description:
Compiling MySQL 5.4 on 32-bit linux fails. The error I get is this (trail of the make):
gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -I../../include -I../../regex -I../../storage/innobase/include -I../../sql -I.    -O3    -DUNIV_LINUX -MT libinnobase_a-log0log.o -MD -MP -MF .deps/libinnobase_a-log0log.Tpo -c -o libinnobase_a-log0log.o `test -f 'log/log0log.c' || echo './'`log/log0log.c
/tmp/ccuIAiMy.s: Assembler messages:
/tmp/ccuIAiMy.s:1915: Error: bad register name `%dil'
make[2]: *** [libinnobase_a-log0log.o] Error 1
make[2]: Leaving directory `/home/karlsson/mysql-5.4.0-beta/storage/innobase'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/karlsson/mysql-5.4.0-beta/storage'
make: *** [all-recursive] Error 1

From what I understand, this is a compiler bug. I upgraded from 4.1.1 to 4.1.2 to no avail. Gcc version is this:
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i386-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i386-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i386-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i386-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i386-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i386-pc-linux-gnu/4.1.2/include/g++-v4 --host=i386-pc-linux-gnu --build=i386-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)

I am pretty sure this is related to bug #45057. That one was closed as this was cygwin, but fact is, the error is from the compiler in the build, and this is the same old gcc.

The configure commandline was simple:
./configure --with-plugins=max-no-ndb

How to repeat:
On a 32-bit Linux platform with gcc 4.1.2 (or 4.1.1 it seems, but this is probalem is probably present in more versions of gcc, I have tried on an old machine with SuSE Linux on and gcc 3.3.1, and it has the same problem), download MySQL 5.4, configure to include innodb and then make

Suggested fix:
I don't know what the fix is, this is beyond me. From what I could google though, this seems to be related to the gcc optimizer and inline code. Using this knowledge, I have a work-around, so the thing will build at lease, which is to configure with less optimization:
./configure --with-plugins=max-no-ndb CFLAGS="-O2"

Thank you for the report.

Verified as described. Problem is not repeatable on 64-bit Linux

Bug #45057 was marked as duplicate of this one.

I take it back. It's a bug in the source. Assigning to Ståle, since the bug appears in 5.4. The following patch fixes it:

=== modified file 'include/atomic/x86-gcc.h'
--- include/atomic/x86-gcc.h	2006-12-27 01:23:51 +0000
+++ include/atomic/x86-gcc.h	2009-05-29 10:20:28 +0000
@@ -35,7 +35,7 @@
   asm volatile (LOCK "; xadd %0, %1;" : "+r" (v) , "+m" (*a))
 #endif
 #define make_atomic_swap_body(S)				\
-  asm volatile ("; xchg %0, %1;" : "+r" (v) , "+m" (*a))
+  asm volatile ("; xchg %0, %1;" : "+q" (v) , "+m" (*a))
 #define make_atomic_cas_body(S)					\
   asm volatile (LOCK "; cmpxchg %3, %0; setz %2;"		\
                : "+m" (*a), "+a" (*cmp), "=q" (ret): "r" (set))

Background:
The make_atomic_swap_body macro is later used to create a bunch of atomic swap functions that operate on operands of various sizes. One of these functions operates on 8-bit integers. This means that when a register is used to store one of the operands, it must be one where the lower 8 bit are accessible. However, the constraint "r" only selects any general-purpose register. What happens here is that the compiler chooses the EDI register, which fulfills the r constraint, but whose lower 8 bit are not accessible on x86. The reason why this later causes it to access an invalid register is that on x86_64, the lower 8 bit of EDI are accessible as DIL. So the compiler bug is that it doesn't know it's producing code for the wrong architecture, but the real cause is that we try to do something that is impossible on x86. As a fix, the "q" constraint may be used instead of "r" to select a register whose lower 8 bit are accessible. 

The broken code is also in earlier versions, but it is my understanding that we don't use the atomic functions on 8-bit operands, hence this only became visible with the innodb changes in 5.4.

From Timothy:
fyi, that bug shouldn't affect our builds, as the compiler we're using should work fine.  so i'll not do anything with that bug unless something turns up indicating that this is a problem for the current build [5.4.1].

Trudy, Tim, it's NOT a compiler bug. If the build works, it works because the compiler randomly chooses a register that can be used in this context!

If it can be compiled on 32 bit Linux - What is the chance for 32 bit Windows.

5.4 has a few features that I have been REALLY waiting for  for over 4 years.  Signals & Output parameters

David, some of the changes were originally written for Linux so take a bit of time to port for Windows. You should also check that the release of 5.4 that you look at has the changes you want, since they are only gradually being merged in to it, regardless of operating system. The descriptions of what will be there are likely to be ahead of what is in the preview releases at present.

Thanks for the update.
As a MySQL user from way back (V3) I have been eagerly awaiting Stored Procedures and triggers. Although they have been implemented in 5.1 there has been some drastic limitation.

1. No easy way to signal back to the calling routine an error message within the SP. Currently I am passing back a recordset with thouse values but it is not native and it causes endless issues.

2. Currenly with MySQL SP - one cannot have an output parameter. I have raised several bugs on this but to no avail. Likewise my solution is as above and again this causes issues.

Both MSSQL and Oracle have these features and it makes developing client applications that use them very easy.

I.e. - with point 1 - creating user define 'errors' like "Customer is Deleted' or 'Invoice Amount cannot be 0' means that that database can become part of the business layer regardless of the client application.

With point 2 - one can call an add record and return back the new ID as part of the paramets, and an empty recordset for population.  At present only the recordset can be returned.

Put myself in as a reviewer to make sure that the fix removes the
disabling of inlining that I added in 5.4 is removed when this is
fixed.

Bug: http://bugs.mysql.com/bug.php?id=45399 marked as duplicate of this one.

Based on Daniel's detailed explanation of what caused this problem the solution of changing from using "r" constraint to using "q" constraint for register selection should solve this problem.

Marking the patch approved.

Pushed to 5.4.2

Noted in 5.4.2 changelog.

A problem of compiler register misallocation on 32-bit Linux was corrected.

Pushed into 5.4.4-alpha (revid:alik@sun.com-20090916063112-8hjmu6wkxfx5qxf4) (version source revid:guilhem@mysql.com-20090708213845-36vjraclcpz7mwlq) (merge vers: 5.4.4-alpha) (pib:11)

The 5.1 branch has this same issue, and Daniel Fischer's patch applies to 5.1 cleanly too. Please change the 5.1 branch also.
Thanks, Günter.