Svadev mailing list

[Santosh Nagarakatte <santoshn AT cis.upenn.edu>]

John,

Thanks. Even I thought about the same process to inline the checks.
I tried a few things to get it inlined but was not successful.

However I realized that the core problem was in getting LTO to work
with clang on linux.
I was not able to get it working by following the instructions at
http://llvm.org/docs/LinkTimeOptimization.html

clang -O4 a.c -o a.o
clang -c main.c -o main.o

file a.o  displays
a.o: LLVM Bitcode

clang a.o main.o -o main.out

has the following errors

/usr/bin/ld: error: a.o:1:3: invalid character
/usr/bin/ld: error: a.o:1:3: syntax error, unexpected $end
/usr/bin/ld: error: a.o: not an object or archive
/usr/bin/ld: main.o: in function main:main.c(.text+0x30): error:
undefined reference to 'foo1'
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

I have the Gold Linker installed in the system

/usr/bin/ld --version displays
GNU gold (GNU Binutils for Ubuntu 2.21.0.20110327) 1.11

Any suggestions on what I am doing wrong?

Thanks,
Santosh



On Wed, Dec 7, 2011 at 12:37 AM, John Criswell 
<criswell AT illinois.edu>
 wrote:
> On 12/6/11 1:33 AM, Santosh Nagarakatte wrote:
>
> [snip]
>
>
> Let me know if there is a way I can inline the SafeCode checks?
>
>
> First, please do an svn up.  I believe I fixed a bug the other day in which
> we weren't running mem2reg before the SAFECode instrumentation passes.
>
> What I think we really need to do is to compile the run-time libraries into
> LLVM bitcode using the libLTO infrastructure.  That may be as simple as
> telling it to generate archives using -O4 level optimization or higher.
>
> Come to think of it, I think this approach would work for people who are
> using libLTO and people who are not.  If libLTO isn't installed before
> SAFECode is built, then -O4 should just generate machine code.  If libLTO is
> installed, then -O4 will generate bitcode.
>
> Another thing one could do is to remove some of the _ui() calls (such as
> funccheck_ui() and poolcheck_ui()).  Some of them do nothing at all (because
> there's no reliable check to do if the compiler doesn't know about all the
> memory objects to which the pointer can point); others can do some checks
> (such as poolcheck_ui(), which can check that a memory dereference only
> accesses bytes within a valid memory object is a memory object can be
> found), but those checks may not be worth the overhead when in debug mode.
>
> Finally, PR#10774 needs to be fixed.
>
> -- John T.
>
>
> Santosh
>
>
> --
> Santosh G Nagarakatte,
> PhD Student,
> Computer and Information Science Department
> University of Pennsylvania,
> Philadelphia-19104
> http://www.cis.upenn.edu/~santoshn
>
>
>
>
> _______________________________________________
> svadev mailing list
> svadev AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/svadev
>
>



-- 
Santosh G Nagarakatte,
PhD Student,
Computer and Information Science Department
University of Pennsylvania,
Philadelphia-19104
http://www.cis.upenn.edu/~santoshn