search for: shadowstackcollector

...;ve no idea if it is correct > or whether you should be committing it. > I've added some missing files, removed LLVMBuilder.h and added IRBuilder.h and added the BrainF example (as I had to make changes to it for the patch). The only changes that I'm not 100% happy with are the ShadowStackCollector changes. The code will currently assert if the BasePtr passed in to the ShadowStackCollector is a constant as the GEP will be a constant. If we want to make the ShadowStackCollector support constant folding, more changes are required. None of the tests in the DejaGNU test suite or the full llvm...

Hi Dominic, +//===-- llvm/Support/IRBuilder.h - Builder for LLVM Instrs -----*- C++ -*-===// is this line the right length? It seems shorter than the similar lines below like this one: +//===----------------------------------------------------------------------===// + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, + const char *Name =

...lass > (or rather, the assembly generated in the lowering passes) and llvm_gc_*? > > Yes. > > If that is the case, then I agree, it's a poor name -- at least it got me > confused. :-P It's hard to come up with good alternatives, though. Hmm. > > I looked a bit at the ShadowStackCollector class, and suddenly it makes much > more sense. But I fail to find any implementations of llvm_gc_allocate and > friends? > > llvm_gc_* are optional interfaces. If you want your allocation routines to > look different, then you're free to do so. I consider that section of the &gt...

Everything described in GarbageCollection.html should now be live. Phew! The collectors could use a review, but they compile, have no impact unless used, and tests would otherwise have had to be XFAILed waiting on them. The ShadowStackCollector has one issue that may be of interest in that it adds constant globals in a runOnFunction context. This is bad in theory, but actually is entirely safe for both JIT and llc from at least a code generation perspective. (Can this invalidate any analyses used during code generation?) Since llc...

...is accessed by both my llvm::Collector subclass (or rather, the assembly generated in the lowering passes) and llvm_gc_*? If that is the case, then I agree, it's a poor name -- at least it got me confused. :-P It's hard to come up with good alternatives, though. Hmm. I looked a bit at the ShadowStackCollector class, and suddenly it makes much more sense. But I fail to find any implementations of llvm_gc_allocate and friends? - Simon

2008/7/24 Gordon Henriksen <gordonhenriksen at me.com>: >> OK, so for instance if I wanted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and

..._gc_allocate, and > llvm_gc_collect Yes. Your implementation of the llvm_gc_* functions should be compiled into a library and linked with your executable. > (llvm_cg_walk_gcroots is provided by the Collector framework, right?) An implementation of llvm_cg_walk_gcroots compatible with ShadowStackCollector is provided in the llvm/runtime directory. You can copy it into your runtime. > in those methods, how do I access the Collector object instantiated > by LLVM? I'm not sure the purpose of doing so—llvm::Collector (poorly named; I'm open to suggestions) exists only in the compil...

...bclass (or rather, the assembly generated in the > lowering passes) and llvm_gc_*? Yes. > If that is the case, then I agree, it's a poor name -- at least it > got me confused. :-P It's hard to come up with good alternatives, > though. Hmm. > > I looked a bit at the ShadowStackCollector class, and suddenly it > makes much more sense. But I fail to find any implementations of > llvm_gc_allocate and friends? llvm_gc_* are optional interfaces. If you want your allocation routines to look different, then you're free to do so. I consider that section of the document...

...%t0 = add i32 99,0 %t1 = load i32** %pa ;%t2 = getelementptr i32** %t1, i32 0 store i32 %t0, i32* %t1 store i32* null, i32** %pa; say it's dead ret void } define void @main() { call void @foo() call void @llvm_gc_collect() ret void } Naturally I find ShadowStackCollector.cpp but even crazy links like this: gcc -lLLVMLinker -lLLVMipo /usr/local/lib/LLVMInterpreter.o - lLLVMInstrumentation /usr/local/lib/LLVMExecutionEngine.o /usr/local/ lib/LLVMJIT.o -lLLVMDebugger -lLLVMBitWriter /usr/local/lib/LLVMX86.o -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts - l...

...::node *CollectorRegistry::Tail = 0; template<> CollectorRegistry::listener *CollectorRegistry::ListenerHead = 0; template<> CollectorRegistry::listener *CollectorRegistry::ListenerTail = 0; Afterwards, the most important features work more or less as to be expected: // ShadowStackCollector.cpp CollectorRegistry::Add<ShadowStackGC> Y("shadow-stack", "Shadow-stack collector, for uncooperative code generators"); // llc.cpp static cl::opt<const CollectorRegistry::entry*, false, CollectorRegistry::Parser> GC("gc", cl::desc(&quo...

This allows the use of shadow stack from the llvm-c API. I am not sure this is the place to insert the include, though. Index: include/llvm-c/ExecutionEngine.h =================================================================== --- include/llvm-c/ExecutionEngine.h (revision 56175) +++ include/llvm-c/ExecutionEngine.h (working copy) @@ -24,6 +24,7 @@ #ifdef __cplusplus extern "C" {

...ry 2008 02:32:47 Gordon Henriksen wrote: > Everything described in GarbageCollection.html should now be live. Phew! > > The collectors could use a review, but they compile, have no impact > unless used, and tests would otherwise have had to be XFAILed waiting > on them. > > The ShadowStackCollector has one issue that may be of interest in that > it adds constant globals in a runOnFunction context. This is bad in > theory, but actually is entirely safe for both JIT and llc from at > least a code generation perspective. (Can this invalidate any analyses > used during code generation...

...ess following a 'call' instruction), and the ints indicate the offsets of the live roots within the stack frame. LLVM does not define such a data structure, but the runtime-specific Collector subclass and the GC runtime itself must agree to a common format in order to interoperate. ShadowStackCollector uses a completely alternative methodology. A shadow stack could be implemented in user code without any special support. (Indeed, it is implemented entirely as an LLVM IR -> LLVM IR transformation!) On Apr 21, 2008, at 19:12, Terence Parr wrote: > On Apr 20, 2008, at 6:52 PM, Gordon...

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of

...structions.h U include/llvm/GlobalAlias.h U include/llvm/Constants.h U include/llvm/User.h U include/llvm/InstrTypes.h U include/llvm/Function.h U tools/bugpoint/CrashDebugger.cpp U tools/bugpoint/Miscompilation.cpp U lib/Analysis/ScalarEvolutionExpander.cpp U lib/CodeGen/ShadowStackCollector.cpp U lib/CodeGen/IntrinsicLowering.cpp U lib/Linker/LinkModules.cpp U lib/Target/X86/X86TargetAsmInfo.cpp U lib/Bitcode/Reader/BitcodeReader.cpp U lib/ExecutionEngine/JIT/JIT.cpp U lib/VMCore/Instructions.cpp U lib/VMCore/Constants.cpp U lib/VMCore/AutoUpgrade.cpp U lib/...