Bug 679489 - /usr/lib/openmpi/lib/libopen-pal.so.1 is DT_TEXTREL
Summary: /usr/lib/openmpi/lib/libopen-pal.so.1 is DT_TEXTREL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openmpi
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 678890
TreeView+ depends on / blocked
 
Reported: 2011-02-22 17:48 UTC by Jakub Jelinek
Modified: 2014-08-31 23:30 UTC (History)
3 users (show)

Fixed In Version: openmpi-1.5-3.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-03 04:49:43 UTC
Type: ---
Embargoed:


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

Description Jakub Jelinek 2011-02-22 17:48:30 UTC
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-23 00:50:14 UTC
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()).  */                                        
#if OPAL_HAVE_INLINE_ATOMIC_ADD_32 || OPAL_HAVE_ATOMIC_CMPSET_32
static inline
#endif
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 OPAL_HAVE_ATOMIC_CMPSET_32

#if !defined(OPAL_HAVE_ATOMIC_ADD_32)
#define OPAL_HAVE_ATOMIC_ADD_32 1
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.
int
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-23 00:52:00 UTC
Created attachment 480307 [details]
openmpi-inline-asm.patch

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-23 00:53:22 UTC
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 15:38:16 UTC
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 16:24:04 UTC
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 22:50:35 UTC
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 18:24:29 UTC
openmpi-1.5-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/openmpi-1.5-3.fc15

Comment 8 Fedora Update System 2011-04-23 01:15:35 UTC
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:
https://admin.fedoraproject.org/updates/openmpi-1.5-3.fc15
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2011-05-03 04:49:38 UTC
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.