Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASan unittest (32-bit) fail to link with fresh googletest #21

Closed
GoogleCodeExporter opened this issue Aug 24, 2015 · 5 comments
Closed

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. rm -rf third_party/googletest
2. svn co http://googletest.googlecode.com/svn/trunk -r608 
third_party/googletest
3. <rebuild ASan>
4. make -f Makefile.old t32

What is the expected output? What do you see instead?
Linker produces error:
/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/lib/asan/../../.
./../build/Release+Asserts/bin/clang++  -faddress-sanitizer 
-DADDRESS_SANITIZER=1 -mllvm 
-asan-blacklist=/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/
lib/asan/tests/asan_test.ignore -mllvm -asan-stack=1 -mllvm -asan-globals=1 
-mllvm -asan-use-call=1 -mllvm -asan-mapping-scale=0   -mllvm 
-asan-mapping-offset-log=-1   -mllvm -asan-use-after-return=0 -DASAN_UAR=0 
-DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DASAN_HAS_BLACKLIST=1 -I../include 
-Wall -fvisibility=hidden -m32 -g -w -lpthread sample1.o sample1_unittest.o 
gtest_main.a -o sample1_unittest

<some clang warnings>

/usr/bin/ld: gtest_main.a(gtest-all.o)(.text+0x7cb7c): unresolvable R_386_PC32 
relocation against symbol `sigaction@@GLIBC_2.0'
/usr/bin/ld: final link failed: Nonrepresentable section on output

Original issue reported on code.google.com by samso...@google.com on 20 Dec 2011 at 8:51

@GoogleCodeExporter
Copy link
Author

I'm also seeing a problem with one of my program (but by compiling it 
statically)

unresolvable R_386_PC32 relocation against symbol `.......`

I've seen it for strcpy, strchar, ... and I don't know why it's happening, what 
could be the source of this problem ?

(GCC compile the same code just fine)

Original comment by mkvtooln...@gmail.com on 26 Jan 2012 at 5:24

@GoogleCodeExporter
Copy link
Author

Does this happens with -faddress-sanitizer?
Could you please send exact linker error messages?


I guess the problem in this issue is that we define our own "sigaction"
with slightly different signature, which confuses ld.
I'm testing a fix for this.

Original comment by samso...@google.com on 30 Jan 2012 at 12:20

@GoogleCodeExporter
Copy link
Author

Yes using Asan it got fixed in my case by reordering my different LDFLAGS i.e. 
putting -lpthread more toward the end and so on.

Original comment by mkvtooln...@gmail.com on 30 Jan 2012 at 12:52

@GoogleCodeExporter
Copy link
Author

r149247 should fix this. Our replacements/wrappers for functions like sigaction 
or strcpy didn't have default visibility.

Original comment by samso...@google.com on 30 Jan 2012 at 1:50

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:12

  • Added labels: ProjectAddressSanitizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant