Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 7/18/13 11:35 AM, Krzysztof Cieniuch wrote:
> Hi,
>
> I'm using CentOS 6.3, clang version 3.2  with latest ld checked out 
> from cvs
> I followed instructions on wiki and installed clang with lto (gold 
> plugin)

Are you using libstdc++ that is installed on your system, or did you 
build compiler_rt?  I've never used compiler_rt with SAFECode.

> I'm having troubles compiling this simple program:
>
> #include<string>
> #include<map>
> #include<iostream>
>
> using namespace std;
> int main(int argc,char** argv){
>     map<string,int> themap;
>     string test(argv[0]);
>
>     themap["key1"]=1;
>     cout << test << endl;
>
>     return 0;
> }
>
> clang++ -g  -O2 -flto -use-gold-plugin -fmemsafety  -o main main.cc  
> -L /opt/SAFECode/lib
>
> FIXME: Ignoring global of size zero: 
> @_ZNSs4_Rep20_S_empty_rep_storageE = external global [0 x i64]
> lto-llvm.o-O8q9Q2:ld-temp.o:TargetList: error: undefined reference to 
> 'std::string::_S_compare(unsigned long, unsigned long)'
> lto-llvm.o-O8q9Q2:ld-temp.o:TargetList1: error: undefined reference to 
> 'std::string::_S_compare(unsigned long, unsigned long)'
>
> If I remove -O2 option it links fine.
> What's strange if you comment  out line:  themap["key1"]=1; it will 
> compile.
> What even more strange :-) if you comment out:  cout << test << endl; 
> instead it will also compile any ideas ?

As to why the problem goes away because of some of these changes, I 
think the issue is that:

1) Removing themap["key1"]=1 removes the string comparison, so the 
string comparison method is no longer needed.

2) Removing the cout line means that your program is identical to a 
program that just exits with status 0.  LLVM is optimizing all the other 
code out, so again, the undefined symbol no longer appears in the program.


> Is this bug in clang ld or libstdc++ on centos 6.3 or combination of all.

I took a quick look, and it's a bug in SAFECode's CFI transform. The 
reason why this is happening is because SAFECode creates a global 
variable with a list of function targets.  Included in this list are 
functions with available_externally linkage.  Such functions never get 
emitted into the executable even though they appear in the IR.  I think 
the correct fix is for the CFI pass to not consider such functions as 
valid targets of indirect function calls.

Can you file a bug report with the above information?  I can probably 
get a fix working by late next week (I'm busy until Wednesday on a 
paper).  In the meantime, try working around the problem by not using -O2.

-- John T.



> Thanks
> Krzysztof
> _______________________________________________
> svadev mailing list
> svadev AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/svadev