assembly fails to build on armel/lucid

Bug #491342 reported by Alexander Sack on 2009-12-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glib2.0 (Ubuntu)

Bug Description

latest glib upload failed to build in lucid:

12:52 < asac>
12:53 < asac> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/build/buildd/glib2.0-2.23.0/glib -I.. -I/build/buildd/glib2.0-2.23.0 -DG_LOG_DOMAIN=\"GLib\" -DG_ENABLE_DEBUG
              .deps/gatomic.Tpo -c /build/buildd/glib2.0-2.23.0/glib/gatomic.c -fPIC -DPIC -o .libs/gatomic.o
12:53 < asac> /tmp/cc7twNnB.s: Assembler messages:
12:53 < asac> /tmp/cc7twNnB.s:161: Error: selected processor does not support `swp r3,r5,[r4]'
12:53 < asac> /tmp/cc7twNnB.s:179: Error: selected processor does not support `swp r3,r5,[r4]'

*** Note: this package requires a rebuild when is resolved ***

Alexander Sack (asac) wrote :

blocks armel images.

Not sure if implicit-it would help for this case. We probably want to fix assembly properly (and upstream). Dave?

Changed in glib2.0 (Ubuntu):
importance: Undecided → Critical
milestone: none → lucid-alpha-1
status: New → Triaged
Alexander Sack (asac) wrote :

swp is mentioned as a cause of issues on our Thumb2 wiki page: ...

Alexander Sack (asac) wrote :

code failing is here:

static int atomic_spin_trylock (void)
  int result;

  asm volatile (
    "swp %0, %1, [%2]\n"
    : "=&r,&r" (result)
    : "r,0" (1), "r,r" (&atomic_spin)
    : "memory");
  if (result == 0)
    return 0;
    return -1;

Dave, any obvious proper fix we can use ... otherwise we probably want to go for -marm to stop all rdepends of glib from failing.

Matthias Klose (doko) wrote :

as Dave did write on this page: "use the GCC __sync_... intrinsics"

tags: added: armel armv7
Dave Martin (dave-martin-arm) wrote :

[Added the "armv7" tag to help track ARMv7 migration issues.]

Agreed, the best way to solve cases like this is to use the GCC intrinsics instead of inline asm.

The attached patch should hopefully work for this; but I haven't been able to build or test it just yet.

I've tried to modify configure to check for support for the intrinsics in GCC, by doing a link test on a call to __sync_synchronize().
Assuming the support is there, this uses some code in glib/qatomic.c which uses the intrinsics instead of inline asm -- this results in a simpler implementation.

I've also turned on memory barriers to make sure that the code is SMP-safe. Conveniently, the support for this was already in there; I just needed to define how to do a memory barrier and set the appropriate variable in configure.


1) The GCC atomic intrinsics require linux-2.6.13 or higher. This is no problem for Ubuntu, but upstream people using old kernels may get problems, so we might want an extra configure argument to turn on my modifications, and pass it from the build rules.

2) People using old compilers won't get the benefits, and will fall back to the SWP-based code. Again, this is not a problem for Ubuntu, but may affect upstream people using older tools. If this is seen as an issue we could include some inline asm which reproduces the intrinsics' behaviour as an additional fallback, if building for -march=armv6 or above (for older architectures, SWP is the right way since nothing else existed there).

Alexander Sack (asac) wrote :

thx a lot, Dave. we are testing your patch now ... stay tuned.

Dave Martin (dave-martin-arm) wrote :

I got a good build, but it's not quite right... the __sync_synchronize() calls compile away to nothing, which is not what's intended.

For now, the package builds and should run fine on uniprocessor platforms, so this should unblock you, but I'll provide an additional patch shortly once I've worked out what the problem is...

In the meantime, can you disassemble debian/build/deb/glibc/gatomic.o (if you still have the build tree), and double-check check whether there is a call to __sync_val_compare_and_swap_4 in atomic_spin_lock ?

This will confirm that configure is working correctly.

You should also see the following if things worked correctly:

build log:
checking whether to use assembler code for atomic operations... arm
checking whether GCC supports atomic intrinsics... yes


description: updated
Dave Martin (dave-martin-arm) wrote :

This patch converts to a cleaner and slightly more efficient implementation, avoiding the need for the explcit __sync_synchronize() in atomic_spinlock_release()

This patch should apply on top of the patch stack in debian/patches, assuming that patch attached above has already been merged.

Note that autoconf will need to be run again before pushing the source package update, since is updated.

My test build hasn't finished yet, but it seems to be going OK.

Alexander Sack (asac) wrote :

glib2.0 (2.23.0-1ubuntu2) lucid; urgency=low

  * add 70_glib2.0-gatomic-arm.patch to fix FTBFS with arm thumb2 support
    (Thanks to Dave Martin < <email address hidden>> for the fix)

 -- Oliver Grawert < <email address hidden>> Thu, 03 Dec 2009 19:15:20 +0100

Changed in glib2.0 (Ubuntu):
status: Triaged → Fix Released
Alexander Sack (asac) wrote :

also upstreamed the combined patch with your improvements included.

Dave Martin (dave-martin-arm) wrote :

Thanks for this.

My build failed, but I think this may be due to some autoconf version mismatch or similar, or incorrect versions of some build dependency. However, a .so was build successfully and looks correct (notwithstanding the missing __sync_synchronize() calls resulting from

/bin/bash: line 20: @GTKDOC_REBASE@: command not found
make[6]: *** [install-data-local] Error 127
make[6]: Leaving directory `/home/ubuntu/src/glib2.0/glib2.0-2.23.0/debian/build/deb/docs/reference/glib'

Unless someone else gets the same problem, this doesn't look like it's related in any way to my changes.

Changed in glib:
status: Unknown → Invalid
Changed in glib:
importance: Unknown → High
status: Invalid → Unknown
Changed in glib:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.