On Mon, 01 Oct 2012 15:06:49 +0200, Mehdi Dogguy wrote:

> >I've prepared an NMU for libatomic-ops (versioned as 
> >7.3~alpha1+git20111031-1.1) and
> >uploaded it to DELAYED/2. Please feel free to tell me if I
> >should delay it longer.
> We may need this patch after all :) It seems that #632604 and sid's
> libatomic-ops cannot be unblocked for Wheezy (due to very large
> changes in its codebase). Could you please prepare an upload
> targetting testing-proposed-updates?

Here we are, the same patch applied against the version in testing,
and the build tested in a wheezy i386 cowbuilder chroot.

Ian, if your busy I'm happy to upload the fix (if Mehdi is ok with
the diff).

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Flying Pickets
diff -u libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
--- libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
+++ libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
@@ -1,3 +1,13 @@
+libatomic-ops (7.2~alpha5+cvs20101124-1.1) testing-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Fix "FTBFS on i386": apply patch from upstream git repo:
+    https://github.com/ivmai/libatomic_ops/commit/30cea1b#diff-0
+    Thanks to Emanuele Aina for the pointer.
+    (Closes: #632604)
+
+ -- gregor herrmann <gre...@debian.org>  Tue, 02 Oct 2012 17:31:16 +0200
+
 libatomic-ops (7.2~alpha5+cvs20101124-1) unstable; urgency=low
 
   * Closes: 604753 -- Update from upstream CVS, fixes ARM Thumb-2 mode
only in patch2:
unchanged:
--- libatomic-ops-7.2~alpha5+cvs20101124.orig/src/atomic_ops/sysdeps/gcc/x86.h
+++ libatomic-ops-7.2~alpha5+cvs20101124/src/atomic_ops/sysdeps/gcc/x86.h
@@ -148,13 +148,16 @@
   /* If PIC is turned on, we can't use %ebx as it is reserved for the
      GOT pointer.  We can save and restore %ebx because GCC won't be
      using it for anything else (such as any of the m operands) */
-  __asm__ __volatile__("pushl %%ebx;"   /* save ebx used for PIC GOT ptr */
-                       "movl %6,%%ebx;" /* move new_val2 to %ebx */
+  /* We use %edi (for new_val1) instead of a memory operand and swap    */
+  /* instruction instead of push/pop because some GCC releases have     */
+  /* a bug in processing memory operands (if address base is %esp) in   */
+  /* the inline assembly after push.                                    */
+  __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
                        "lock; cmpxchg8b %0; setz %1;"
-                       "pop %%ebx;"     /* restore %ebx */
+                       "xchg %%ebx,%6;" /* restore ebx and edi */
                        : "=m"(*addr), "=a"(result)
                        : "m"(*addr), "d" (old_val2), "a" (old_val1),
-                         "c" (new_val2), "m" (new_val1) : "memory");
+                         "c" (new_val2), "D" (new_val1) : "memory");
 #else
   /* We can't just do the same thing in non-PIC mode, because GCC
    * might be using %ebx as the memory operand.  We could have ifdef'd

Attachment: signature.asc
Description: Digital signature

Reply via email to