Bug 679489 - /usr/lib/openmpi/lib/libopen-pal.so.1 is DT_TEXTREL
/usr/lib/openmpi/lib/libopen-pal.so.1 is DT_TEXTREL
Product: Fedora
Classification: Fedora
Component: openmpi (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jay Fenlason
Fedora Extras Quality Assurance
Depends On:
Blocks: 678890
  Show dependency treegraph
Reported: 2011-02-22 12:48 EST by Jakub Jelinek
Modified: 2014-08-31 19:30 EDT (History)
3 users (show)

See Also:
Fixed In Version: openmpi-1.5-3.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-05-03 00:49:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
openmpi-inline-asm.patch (516 bytes, patch)
2011-02-22 19:52 EST, Jakub Jelinek
no flags Details | Diff

  None (edit)
Description Jakub Jelinek 2011-02-22 12:48:30 EST
In openmpi-1.5-2.fc15.i686
readelf -Wd /usr/lib/openmpi/lib/libopen-pal.so.1 | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0
which is wrong, and causes valgrind build failure:
configure:8503: checking primary target for usable MPI2-compliant C compiler and mpi.h                                                             
configure:8527: /usr/lib/openmpi/bin/mpicc -o conftest -m32   conftest.c  >&5                                                                      
/usr/lib/openmpi/bin/mpicc: error while loading shared libraries: /usr/lib/openmpi/lib/libopen-pal.so.1: cannot restore segment prot after reloc: Permission denied

All the TEXTREL violations are in calls to opal_atomic_add_32 and opal_atomic_sub_32, like:
00041f3b  0002cb02 R_386_PC32             0001d116   opal_atomic_add_32
00010672  0001e902 R_386_PC32             0001d126   opal_atomic_sub_32

Please fix this.
openmpi-1.4.3-7.fc14.i686 was correct.
Comment 1 Jakub Jelinek 2011-02-22 19:50:14 EST
The TEXTRELs are because opal/include/opal/sys/atomic.h has
/* OPAL_HAVE_INLINE_ATOMIC_*_32 will be 1 if <arch>/atomic.h provides
   a static inline version of it (in assembly).  If it's 0 but
   OPAL_HAVE_ATOMIC_CMPSET_32 is 1, then atomic_impl.h (below) will
   define a static inline version of it (in C, using
   atomic_cmpset_32()).  */                                        
static inline
int32_t opal_atomic_add_32(volatile int32_t *addr, int delta);
(and similarly for sub), but there is no definition in that header.
OPAL_HAVE_INLINE_ATOMIC_ADD_32 is 0, but OPAL_HAVE_ATOMIC_CMPSET_32 is non-zero, thus if the above comment is right, atomic_impl.h should be defining those.

But that header has:

#if !defined(OPAL_HAVE_ATOMIC_ADD_32)
static inline int32_t
opal_atomic_add_32(volatile int32_t *addr, int delta)
   int32_t oldval;
   do {
      oldval = *addr;
   } while (0 == opal_atomic_cmpset_32(addr, oldval, oldval + delta));  
   return (oldval + delta);
#endif  /* OPAL_HAVE_ATOMIC_CMPSET_32 */

but as OPAL_HAVE_ATOMIC_ADD_32 is defined, just defined to 0, this isn't included.  Probably this isn't tested.

The GCC inline assembly test in configury fails because the inline asm it is testing is wrong.
main ()
int ret = 1;
int negone = -1;
__asm__ __volatile__ ("xaddl %1,%0" : "=m"(ret), "+r"(negone));
return ret;
return 0;
doesn't tell gcc that "m" (ret) is used, therefore it doesn't have to assign value 1 to it.  Seems fixing this cures the TEXTREL, but I haven't analyzed the inline asms openmpi is actually using whether they aren't similarly buggy.
Comment 2 Jakub Jelinek 2011-02-22 19:52:00 EST
Created attachment 480307 [details]

Patch which fixes the inline asm configury detection and with which the library is no longer DT_TEXTREL.  That said, upstream should be at least told that it is buggy if inline asm configury fails for ia32.
Comment 3 Jakub Jelinek 2011-02-22 19:53:22 EST
Could be "+m" (ret) too, but I think the "=m" + "m" variant should cover even prehistoric buggy gccs while "+m" might not work well there.
Comment 4 Jakub Jelinek 2011-03-14 11:38:16 EDT
Any progress here (just applying the patch and building + bodhi ought to be enough)?  This is blocking valgrind upgrade to 3.6.1 in F-15 (or any valgrind rebuild whatsoever) for 3 weeks already.
Comment 5 Jay Fenlason 2011-03-17 12:24:04 EDT
Built in Rawhide.  If you confirm that the build fixes the problem, I can backport it to F15, et all.
Comment 6 Jakub Jelinek 2011-03-17 18:50:35 EDT
Yeah, valgrind builds just fine against openmpi-{,devel-}-1.5-3.fc16 on i?86, while it doesn't against openmpi-{,devel-}-1.5-2.fc15.  None of the openmpi shared libs are DT_TEXTREL anymore as well.

Please build it also into f15, thanks.
Comment 7 Fedora Update System 2011-04-22 14:24:29 EDT
openmpi-1.5-3.fc15 has been submitted as an update for Fedora 15.
Comment 8 Fedora Update System 2011-04-22 21:15:35 EDT
Package openmpi-1.5-3.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openmpi-1.5-3.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2011-05-03 00:49:38 EDT
openmpi-1.5-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.