Bug 521575 - Dynamic linker issue with strcmp
Dynamic linker issue with strcmp
Status: CLOSED DUPLICATE of bug 529965
Product: Fedora
Classification: Fedora
Component: llvm (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Bryan O'Sullivan
Fedora Extras Quality Assurance
http://code.google.com/p/pure-lang/is...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-06 23:41 EDT by Michel Alexandre Salim
Modified: 2009-10-22 04:46 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-22 04:46:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Self-contained test program (1.13 KB, text/plain)
2009-09-24 15:06 EDT, Michel Alexandre Salim
no flags Details

  None (edit)
Description Michel Alexandre Salim 2009-09-06 23:41:52 EDT
Description of problem:
An issue with Rawhide glibc's dynamic linker is exposed when compiling Pure (URL referenced above); this issue is not present in Fedora 11.

Version-Release number of selected component (if applicable):
glibc-2.10.90-20.x86_64

How reproducible:
Always

Steps to Reproduce:
1. yum install llvm-devel gmp-devel readline-devel gsl-devel flex
2. Compile pure version 0.34
2. make check
  
Actual results:
Test 11 causes a SIGSEGV; tests 15,24,25 fail. All involve strcmp which is dlsym()-ed.

Expected results:
These tests should not fail. Also, they do not fail on %{ix86}, where due to an LLVM bug, LLVM (and thus Pure) is not compiled with PIC.

Pure SVN now has a workaround where strcmp is declared extern, which works but is kludgy.

Additional info:
Comment 1 Andreas Schwab 2009-09-07 05:03:18 EDT
Please provide a self-contained test case.
Comment 2 Michel Alexandre Salim 2009-09-09 00:15:09 EDT
This is the smallest test case so far; it requires llvm, pure and pure-devel to be installed:

Test case:
http://code.google.com/p/pure-lang/issues/detail?id=13#c52

LLVM 2.6-0.3.pre1 from Rawhide should work, and here is the Koji scratch build for Pure:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1663002

I'll try and get a test case that relies only on LLVM to work, but it's worthwhile to note that the problem is not caused by LLVM 2.6 (it occured when Rawhide had LLVM 2.5), and that the unpatched pure 0.34 works fine on F-11.
Comment 3 Andreas Schwab 2009-09-10 08:09:38 EDT
Where do I get pure-devel?
Comment 4 Michel Alexandre Salim 2009-09-11 15:26:43 EDT
Ah, I forgot to post the link. Pure is under review at the moment, here is the Bugzilla entry:

https://bugzilla.redhat.com/show_bug.cgi?id=488563

Links to srpm and Koji builds are available there.
Comment 5 Andreas Schwab 2009-09-14 04:45:45 EDT
What is the testcase supposed to do?
Comment 6 Michel Alexandre Salim 2009-09-24 15:06:11 EDT
Created attachment 362558 [details]
Self-contained test program

See testmod.pure for how testmod.cc is invoked -- basically it's passed the dynamically-obtained address of strcmp, and does some sanity tests to make sure that strcmp works.

This is what I obtained using the testcase, when I had the version of pure installed without the workaround:

g++ -shared -fPIC -o testmod.so testmod.cc -lpure
[michel@erdos testmod]$ pure -q -i testmod.pure 
> test (addr "strcmp") "a" "b";
s = 'a', t = 'b'
fp = 0x7f5ce6f1ae60, strcmp = 0x7f5ce6fc1c00
Function pointers are not identical.
testing fp: -419685376, -419685376, -419685376
testing strcmp: 0, -1, 1
-419685376

A test case that does not use Pure is attached, to compile, do

g++ -o problem problem.cc /usr/lib64/llvm/libLLVMSystem.a -ld
Comment 7 Andreas Schwab 2009-09-25 06:03:03 EDT
I'm getting fp == NULL.
Comment 8 Andreas Schwab 2009-10-05 11:22:53 EDT
$ pure -q -i testmod.pure
LLVM ERROR: Allocation failed when allocating new memory in the JIT
Can't allocate RWX Memory: Permission denied
Comment 9 Michel Alexandre Salim 2009-10-05 16:54:27 EDT
Interesting. Does 'setenforce 0' help?

Also, the problem (as the standalone test case demonstrates) is really between LLVM's dlsym and glibc, since the same dlsym() invocation on F-11 retrieves the correct function pointer. Pure simply uses dlsym to let users call arbitrary libc functions at runtime.
Comment 10 Andreas Schwab 2009-10-06 05:35:38 EDT
That appears to be a bug in llvm::sys::DynamicLibrary::SearchForAddressOfSymbol.  Since there are no debugging symbols I have no idea what it does.
Comment 11 Andreas Schwab 2009-10-22 04:46:49 EDT

*** This bug has been marked as a duplicate of bug 529965 ***

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