On Sun, 3 Sep 2006, Tanya M. Lattner wrote:>> BTW, how can I run all tests only on LLC to reduce the amount of time to >> wait until tests are finished, if it's possible? > > In my previous reply to your question, I suggested you look at > TEST.llc.Makefile and TEST.llc.report in the test directory. Modifying > those makefile/report files to use your register allocator will do what > you want.Tanya's right, if you want full control over what is being run, you should write your own test script. If you really really want to use the nightly tester script, you can pass DISABLE_CBE=1 DISABLE_JIT=1 on the make command line to disable those runs. If the test output claims that llc-beta fails, then your register allocator is producing incorrect code. In a multisource directory, if you use 'make bugpoint-llc-beta' in some failing test directory, bugpoint will automatically reduce the failure to a smaller example for you. -Chris -- http://nondot.org/sabre/ http://llvm.org/
I was just wondering what existing work has been done on proving programs type-safe using the LLVM framework? I've read the paper on memory-safety for embedded systems, but that's not quite what I'm looking for, as my application (which involves running untrusted code within a trusted context) might fail if a pointer to one object became a pointer to another of the same type. Looking at the documentation, it seems a trivial check for type-safety would be simply to ensure that the program didn't use any 'cast' instructions, only used the memory allocation facilities of a trusted garbage collector, and didn't contain any zero-length arrays (as these might be used for unsafe pointer arithmetic). However I guess that in the real world, these constraints would be almost impossible to program to (e.g., my simple C++ test programs suggest that it's impossible to write any non-trivial C++ program that doesn't generate a 'cast'), so there must be circumstances that allow such constructs. Has any work been done on this? If not, what pointers would you give for places to start? Thanks, Jules
On Mon, 4 Sep 2006, Jules wrote:> Has any work been done on this? If not, what pointers would you give > for places to start?Here is one pointer: http://safecode.cs.uiuc.edu/ -Chris -- http://nondot.org/sabre/ http://llvm.org/
Jules, The link Chris forwarded (safecode.cs.uiuc.edu) describes the most relevant work so far. But that work aims to make ordinary C and C++ programs memory-safe, without using garbage collection or any other automatic memory management scheme, i.e., allowing dangling pointers but ensuring they are harmless. It also allows any casts that are legal in C. If you want to enforce strict type safety with GC and without arbitrary casts, you should be able to build on top of SAFECode and provide a garbage collector. You'd have to define what pointer casts are legal and check for them. But SAFECode would give you several other checks you need including: -- array bounds (just looking for 0-length arrays isn't enough) -- uninitialized variables -- many stdlib usage checks. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Sep 4, 2006, at 9:04 AM, Jules wrote:> I was just wondering what existing work has been done on proving > programs type-safe using the LLVM framework? I've read the paper on > memory-safety for embedded systems, but that's not quite what I'm > looking for, as my application (which involves running untrusted code > within a trusted context) might fail if a pointer to one object > became a > pointer to another of the same type. > > Looking at the documentation, it seems a trivial check for type-safety > would be simply to ensure that the program didn't use any 'cast' > instructions, only used the memory allocation facilities of a trusted > garbage collector, and didn't contain any zero-length arrays (as these > might be used for unsafe pointer arithmetic). However I guess that in > the real world, these constraints would be almost impossible to > program > to (e.g., my simple C++ test programs suggest that it's impossible to > write any non-trivial C++ program that doesn't generate a 'cast'), so > there must be circumstances that allow such constructs. > > Has any work been done on this? If not, what pointers would you give > for places to start? > > Thanks, > > Jules > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > If the test output claims that llc-beta fails, then your register > allocator is producing incorrect code. In a multisource directory, if you > use 'make bugpoint-llc-beta' in some failing test directory, bugpoint will > automatically reduce the failure to a smaller example for you.Ok. My allocator failed on MultiSource/Applications/Burg test. I run bugpoint and it gives me bugpoint-reduced-simplified.bc. I run llc on this file with all LLVM register allocators and it gives the same result (under gdb): Program received signal SIGSEGV, Segmentation fault. 0x00634572 in (anonymous namespace)::X86DAGToDAGISel::DeleteNode ( this=0x4c3b710, N=0x4c3e5c0) at /llvm/obj/lib/Target/X86/X86GenDAGISel.inc:77 77 SDNode *Operand = I->Val; SEGFAULT seems to come before register allocation pass is being run. Thanks. -- Three things are certain: Death, taxes, and lost data. Guess which has occurred. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060919/4746d9a9/attachment.html>
> > If the test output claims that llc-beta fails, then your register > allocator is producing incorrect code.Ok, I run make TEST=llc report.html with default allocator, not mine. Why LLCBETAOPTION for X86 is local, not linearscan? I've got some tests having * in some columns (for example, in column with register spills count). Does it mean that the test failed? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060919/40bcd3f6/attachment.html>
On Tue, 19 Sep 2006, Anton Vayvod wrote:> Program received signal SIGSEGV, Segmentation fault. > 0x00634572 in (anonymous namespace)::X86DAGToDAGISel::DeleteNode ( > this=0x4c3b710, N=0x4c3e5c0) > at /llvm/obj/lib/Target/X86/X86GenDAGISel.inc:77 > 77 SDNode *Operand = I->Val; > > SEGFAULT seems to come before register allocation pass is being run.Are you using LLVM CVS? If not, please update. If so, please run 'make bugpoint-llc' in that directory and file a bug. This is an instruction selector bug, not yours. We'll be happy to fix it if it's not already fixed in LLVM CVS. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Tue, 19 Sep 2006, Anton Vayvod wrote:> Ok, I run make TEST=llc report.html with default allocator, not mine. > > Why LLCBETAOPTION for X86 is local, not linearscan?We are testing it with the nightly test. To change it, modify the appropriate line (search for -regalloc=local) in llvm-test/Makefile.programs.> I've got some tests having * in some columns (for example, in column with > register spills count). Does it mean that the test failed?I don't know, I don't think anyone has used the llc test with the local register allocator. -Chris -- http://nondot.org/sabre/ http://llvm.org/