Skip to Content.
Sympa Menu

svadev - Re: [svadev] Safecode : Negative False

svadev AT lists.siebelschool.illinois.edu

Subject: Svadev mailing list

List archive

Re: [svadev] Safecode : Negative False


Chronological Thread 
  • From: Vikram Adve <vadve AT illinois.edu>
  • To: John Criswell <criswell AT illinois.edu>
  • Cc: svadev AT cs.uiuc.edu
  • Subject: Re: [svadev] Safecode : Negative False
  • Date: Wed, 9 May 2012 17:03:08 -0500
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/svadev>
  • List-id: <svadev.cs.uiuc.edu>

Doesn't clang have a -internalize option that runs the LLVM internalize pass to mark most things "not external?"

--Vikram
Professor, Computer Science
University of Illinois at Urbana-Champaign




On May 9, 2012, at 9:25 AM, John Criswell wrote:

On 5/9/12 5:50 AM, Umesh Kalappa wrote:
Hi  John,

Was trying run the safecode analysis for the below sample i.e

You need to use the libLTO support in SAFECode to catch errors like the one below.  This is because SAFECode only converts run-time checks from incomplete to complete when the final executable is being created within libLTO.

Here's why:

First, there are two variations of nearly every type of run-time check in SAFECode: incomplete and complete.  Incomplete checks are used when the compiler cannot analyze all of the operations performed on the pointer (because, for example, the pointer is accessible to external library code).  Complete checks are used when the compiler knows everything about a pointer.  Complete checks are very stringent; if they can't find the memory object that a pointer is pointing to, then they print an error.  Incomplete checks do a "best effort" check; if they can figure out which memory object the pointer points to, they do a check.  If they can't, they assume the memory object must come from external library code and assume that everything's okay.

The reason this is needed is to avoid false positives with memory handled by external code.  In your example below, when SAFECode compiles the compilation unit test.c into test.o, it does not know whether or not the global variable ptr is accessed by other functions.  Only within libLTO, when the final executable is being linked together from individual bitcode files, can SAFECode determine that all of the memory accesses to ptr have been identified.

If I use libLTO like so:

/home/criswell/box/x86/llvm/projects/safecode/Debug/bin/clang -m32 -use-gold-plugin -fmemsafety -g -flto -m32 -use-gold-plugin -L/home/criswell/SCTests/install/lib -L/home/criswell/box/x86/llvm/projects/safecode/Debug/lib -o test test.c -m32 -use-gold-plugin -L/home/criswell/SCTests/install/lib -L/home/criswell/box/x86/llvm/projects/safecode/Debug/lib

... then I get the expected output:

SAFECode:Violation Type 0x6 when accessing  0xffffcbb4 at IP=0x8049594

=======+++++++    SAFECODE RUNTIME ALERT +++++++=======
= Error type                            :    Load/Store Error
= CWE ID                                :    416
= Faulting pointer                      :    0xffffcbb4
= Program counter                       :    0x8049594
= Fault PC Source                       :    /home/criswell/SCTests/test/test.c:12
Aborted

A nice feature to add to SAFECode would be a partial CompleteChecks pass that would try to convert incomplete checks to complete checks without using whole program analysis.  It would not be as aggressive as the version in libLTO, but it would make SAFECode more accurate when it is used without libLTO.

-- John T.


[root@localhost simple_player]# cat test.c
int *ptr = (void *) 0;

void func()
{
 int a = 10;
 ptr = &a;
}

int main()
{
 func();
 return *ptr;
}

[root@localhost simple_player]# clang -g -fmemsafety test.c
[root@localhost simple_player]# ./a.out
[root@localhost simple_player]#

Where Safecode was unable detect the above dangling pointer issue ,Any lights on this ????

For you reference 
[root@localhost tools]# clang --version
Target: x86_64-unknown-linux-gnu
Thread model: posix

[root@localhost tools]# uname -a
Linux localhost.localdomain 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

Thanks 
~Umesh 


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




Archive powered by MHonArc 2.6.16.

Top of Page