Bug 540426

Summary:	sys-devel/llvm-3.5.1: clang, UndefinedBehaviorSanitizer produces non-PIC output when using std::shared_ptr
Product:	Gentoo Linux	Reporter:	Andrey Vul <andrey.vul>
Component:	[OLD] Core system	Assignee:	LLVM support project <llvm>
Status:	RESOLVED OBSOLETE
Severity:	normal	CC:	andrey.vul, mgorny
Priority:	Normal
Version:	unspecified
Hardware:	AMD64
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	emerge --info

Description Andrey Vul 2015-02-17 22:09:46 UTC

When building a shared library, ld warned of DT_TEXTREL (text relocations). This has been isolated to a relocation of typeinfo data that occurs only when -fsanitize contains ubsan.

This occurs with both -stdlib=libc++ and -stdlib=libstdc++.

Test case:
#include <memory>
std::shared_ptr<int> foo;
// __END__

Reproducible: Always

Steps to Reproduce:
1) Let the test case be named foo.cc.
2) clang -std=c++11 -fsanitize=undefined -fPIC -c foo.cc
3) clang -shared -fPIC foo.o foo.so

Actual Results:  
(-stdlib=libc++):
/usr/bin/x86_64-pc-linux-gnu-ld: a.o: warning: relocation against `typeinfo for void ()' in readonly section `.text.std::__1::shared_ptr<int>::~shared_ptr()[std::__1::shared_ptr<int>::~shared_ptr()]'.
/usr/bin/x86_64-pc-linux-gnu-ld: warning: creating a DT_TEXTREL in object.

(-stdlib=libstdc++):
/usr/bin/x86_64-pc-linux-gnu-ld: a.o: warning: relocation against `typeinfo for int ()' in readonly section `.text'.
/usr/bin/x86_64-pc-linux-gnu-ld: warning: creating a DT_TEXTREL in object.

Expected Results:  
<no output>

Comment 1 Andrey Vul 2015-02-17 22:10:09 UTC

Created attachment 396760 [details]
emerge --info

Comment 2 Andrey Vul 2015-02-17 22:17:55 UTC

Tried -fno-rtti to see whether typeinfo emission could be removed; got:

x86_64-pc-linux-gnu-clang-3.5.1: error: invalid argument '-fsanitize=vptr' not allowed with '-fno-rtti'

So it appears that the vptr sanitizer injects a non-PICable typeinfo, at least for elf-x86_64.

Comment 3 Michał Górny archtester

2018-03-29 07:49:33 UTC

I can't reproduce it with current versions of clang. It's highly likely it has been fixed upstream.