assembly fails to build on armel/lucid

blocks armel images.

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

swp is mentioned as a cause of issues on our Thumb2 wiki page: https://wiki.ubuntu.com/ARM/Thumb2 ...

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;
  else
    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.

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

[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.

Note:

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).

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

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

debian/build/gdeb/config.h
#define G_ATOMIC_ARM_USE_GCC_INTRINSICS 1

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 configure.in is updated.

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

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

upstreamed to https://bugzilla.gnome.org/show_bug.cgi?id=603780

also upstreamed the combined patch with your improvements included.

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 https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872)

/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.