MySQL Bugs: #46718: InnoDB plugin incompatible with gcc 4.1 (at least: on PPC): "Undefined symbol"

Bug #46718	InnoDB plugin incompatible with gcc 4.1 (at least: on PPC): "Undefined symbol"
Submitted:	14 Aug 2009 11:15	Modified:	20 Jun 2010 17:45
Reporter:	Joerg Bruehe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB Plugin storage engine	Severity:	S2 (Serious)
Version:	5.1.38	OS:	Any (gcc 4.1 PPC)
Assigned to:	Satya B	CPU Architecture:	Any

Description:
This problem occurs on "Debian Lenny" running on a PPC CPU ("Pegasos" box) when I use gcc 4.1 as compiler,
it works when I switch the compiler to gcc 4.3 (same box, no other change).

It is reproducible across compiler switches:
success with gcc 4.3, failure with gcc 4.1, success with 4.3, failure with 4.1

Exact compiler versions (most current upgrades for Debian Lenny):
gcc (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
gcc (Debian 4.3.2-1.1) 4.3.2

In the test output for the failure, I see this:
090814  1:42:58 [ERROR] Can't open shared library '/MySQL/REPO/V51/work-5.1
        /storage/innodb_plugin/.libs/ha_innodb_plugin.so'
        (errno: 22 undefined symbol: __sync_lock_test_and_set_1)
090814  1:42:58 [ERROR] Couldn't load plugin named 'innodb' with soname
        'ha_innodb_plugin.so'.
090814  1:42:59 [Note] Starting MySQL Cluster Binlog Thread
090814  1:42:59 [Warning] /MySQL/REPO/V51/work-5.1/sql/mysqld: unknown variable
        'loose-innodb_data_file_path=ibdata1:10M:autoextend'
090814  1:42:59 [ERROR] /MySQL/REPO/V51/work-5.1/sql/mysqld: unknown option
        '--innodb'
090814  1:42:59 [ERROR] Aborting

Checking the ".o" files, I see that plenty reference that symbol, but none defines it.

How to repeat:
Build 5.1.38 (with the InnoDB plugin) using gcc 4.1, at least on PowerPC.

Suggested fix:
Not sure, it may depend on how widespread this is and which platforms use which compiler version.

If gcc 4.3 is sufficiently widespread available, there may be no need to use 4.1.

OTOH, we had some Falcon code which worked with gcc 4.1 but failed with 4.3 (bug#40065), so we might be forced to choose between two evils if these problems persist.

Specific for this gcc 4.1 problem:
I see that using this symbol depends on HAVE_GCC_ATOMIC_BUILTINS which is checked during "configure", and this check succeeds in my log:
configure:29346: checking whether the compiler provides atomic builtins
configure:29382: gcc -o conftest  -Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Wunused-function -Wunused-label -Wunused-value -Wunused-variable -Wunused-parameter  -O3 -fno-omit-frame-pointer -g     conftest.c -lpthread -lcrypt -lnsl -lm  -lpthread >&5
configure:29385: $? = 0
configure:29391: ./conftest
configure:29394: $? = 0
configure:29410: result: yes

So I can't say why this succeeds during "configure" but later fails.

From http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

<quot>
If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated.
</quot>

I suspect gcc is treating PPC as such platform.

There seem to be a bug in gcc, where it doesn't link these generated calls into shared object (and they're hidden in the binary). Thus it is only affecting dynamic build of InnoDB plugin.

An obvious fix is to disable gcc atomic builtins on platforms and with gcc versions that do not support them. Unfortunately it is rather difficult to determine if they're supported by gcc version or by performing test build.

I think gcc 4.1 doesn't have __sync_lock_test_and_set_1 but has __sync_lock_test_and_set_4 or 8.
The type of mutex->lock_word is "byte". if we change the type to "lint", we may be able to build correctly.

Grab and change category since this is an InnoDB Plugin issue.

Sergey,

I think you may wrong in this part:

"There seem to be a bug in gcc, where it doesn't link these generated calls into shared
object (and they're hidden in the binary). Thus it is only affecting dynamic build of
InnoDB plugin."

Can you confirm that the problem does not exist if InnoDB Plugin is linked statically? How do you link it statically?

InnoDB uses the following GCC builtins:

1. __sync_bool_compare_and_swap(long)
2. __sync_bool_compare_and_swap(pthread_t)
3. __sync_add_and_fetch(long)
4. __sync_lock_test_and_set(char)

it assumes they will be present if:

for 1. HAVE_ATOMIC_BUILTINS is defined
for 2. HAVE_ATOMIC_BUILTINS and HAVE_ATOMIC_PTHREAD_T is defined
for 3. HAVE_ATOMIC_BUILTINS is defined
for 4. HAVE_ATOMIC_BUILTINS is defined

HAVE_ATOMIC_BUILTINS is defined in univ.i if HAVE_GCC_ATOMIC_BUILTINS is defined

HAVE_GCC_ATOMIC_BUILTINS is defined by MySQL's top-level ./configure.in if this program compiles and returns 0 when executed:

  int main()
  {
    int foo= -10; int bar= 10;
    if (!__sync_fetch_and_add(&foo, bar) || foo)
      return -1;
    bar= __sync_lock_test_and_set(&foo, bar);
    if (bar || foo != 10)
      return -1;
    bar= __sync_val_compare_and_swap(&bar, foo, 15);
    if (bar)
      return -1;
    return 0;
  }

Obviously there is a mismatch between what is tested to be present and what is used.

InnoDB should test whether what it needs is present instead of relying on foreign macros.

I can now confirm that the issue is tied to that InnoDB version (1.0.4 ?), not to it being used as a plugin:
When building MySQL 5.4.2 (which uses that InnoDB version as a builtin) on that machine using gcc 4.1, the final link of the server fails with these lines:

../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o): In function `mutex_test_and_set':
/V54/work-5.4/storage/innobase/./include/sync0sync.ic:83: undefined reference to `__sync_lock_test_and_set_1'
../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o): In function `mutex_reset_lock_word':
/V54/work-5.4/storage/innobase/./include/sync0sync.ic:114: undefined reference to `__sync_lock_test_and_set_1'
../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o): In function `mutex_test_and_set':
/V54/work-5.4/storage/innobase/./include/sync0sync.ic:83: undefined reference to `__sync_lock_test_and_set_1'
../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o): In function `mutex_reset_lock_word':
/V54/work-5.4/storage/innobase/./include/sync0sync.ic:114: undefined reference to `__sync_lock_test_and_set_1'
../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o): In function `mutex_test_and_set':
/V54/work-5.4/storage/innobase/./include/sync0sync.ic:83: undefined reference to `__sync_lock_test_and_set_1'
../storage/innobase/libinnobase.a(libinnobase_a-ha_innodb.o):/V54/work-5.4/storage/innobase/./include/sync0sync.ic:114: more undefined references to `__sync_lock_test_and_set_1' follow
collect2: ld returned 1 exit status

Joerg, right, it is just that this GCC does not implement __sync_lock_test_and_set() on this platform for 1-byte sized arguments and generates code that links to __sync_lock_test_and_set_1() but noone defines this function.

fix

Attachment: bug46718.diff (application/octet-stream, text), 4.99 KiB.

Here is a patch to fix this bug: http://bugs.mysql.com/file.php?id=12793

Joerg, can you test and confirm that it solves the problem in your environment?

Thanks!

I applied your patch to current 5.4.2, to avoid any issues which might be specific to plugin issues and just use the builtin code, it applied fine.

I am now running a compile, to be followed by a test, and will report the results here.

Once that is done, I will do the same to 5.1 (plugin) and report again.

Thanks for the speedy fix!

Just an intermediate report:
I could build 5.4 with your patch applied using gcc 4.1 on my PPC host,
and it is now taking the tests.

It is still running, so I cannot comment on test success yet.

I will continue this and add reports.

The test run in 5.4 succeeded, no failures.

Now trying the same in 5.1 (plugin).

Similar success in 5.1 (plugin).

For me, your patch was a full success, completely solving the issue.

Joerg, thank you!

Fix as is has been committed in the InnoDB Plugin repo, just changed 133 to 123 + 10 from the previous patch

Attachment: bug46718.diff (application/octet-stream, text), 5.00 KiB.

http://bugs.mysql.com/file.php?id=12813 has been committed in the InnoDB Plugin repo as c5716.

I've gathered another report:
http://forums.mysql.com/read.php?22,66995,66995

Hi,
Sorry, but I've submitted a new bug report: http://bugs.mysql.com/bug.php?id=47198

Vasil,

I don't agree your bug46718.diff file.
Because we can use atomic builtin to fix the hangup possibility on PowerPC SMP.

http://bugs.mysql.com/bug.php?id=47213

Yasufumi, it is best to check whether __sync_synchronize() is available separately and define a separate macro HAVE__SYNC_SYNCRONIZE if it is.

Pushed into 5.1.41 (revid:joro@sun.com-20091014143611-cphb0enjlx6lpat1) (version source revid:satya.bn@sun.com-20091008112837-dxbi1c2rjngpktug) (merge vers: 5.1.40) (pib:13)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)

Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091019131022-2o2ymjfjjoraq833) (merge vers: 5.5.0-beta) (pib:13)

Noted in 5.1.41, 5.5.0, 6.0.14 changelogs.

InnoDB Plugin did not compile using gcc 4.1 on PPC systems.

Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)

Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)

Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)

Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)

Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)

Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)