similar to: [LLVMdev] shadow-stack broken?

Hi, Is it necessary to emit all the calls to @llvm.gcroot in the entry block of each function, or can I emit them anywhere on the function? Thanks, N

Hi, I'm trying to start using gc with llvm, and was trying to get started with the shadow-stack plugin. I'm having trouble putting everything together, even in this simple case. My compiler generates the necessary gcroot instructions and for now I would be glad just being able to walk through the roots and print out some numbers. For example, I have the following my.ll file: my.ll:

The linker is going off in the weeds trying to parse the dwarf unwind info. The CIE has: Leh_frame_common_begin0: .long 0 ## CIE Identifier Tag .byte 1 ## DW_CIE_VERSION .asciz "zLR" ## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in

Hi Everyone, I've managed to create a small example that reproduces the error that I'm seeing when generating code, or running the interpreter: ----------------------------------------------------------------------- @llvm_gc_root_chain = global i8* null declare i8* @malloc(i32) declare void @llvm.gcroot(i8**, i8*) nounwind define i32 @main() gc "shadow-stack" { %value =

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0*

Hi Bill, > However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. GCC recently added support for this, i.e. a situation in which there are only cleanups to be run: it uses the C personality function even if the

Hello, I am running a i7 MacBook Pro 2011. If I write: @g = global double 0.000000e+00 define i32 @main() { entry: %0 = load double* @g %1 = fmul double 1.000000e+06, %0 store double %1, double* @g ret i32 0 } in test.ll and I run > llc test.ll > gcc test.s I get: test.s:12:no such instruction: `vmovsd _g(%rip), %xmm0' test.s:13:no such instruction: `vmulsd LCPI0_0(%rip),

Hi, Some time ago, I reported a bug (PR# 9686) involving gcroot, and the shadow-stack. I don't understand enough of the low-level details to understand what's going on, but I'm still interested in using the shadow-stack. Is there a way to circumvent the problem reported in PR# 9686? Thanks! N

On Fri, Mar 18, 2011 at 4:23 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi Eli, > > I'm using 2.8. Ouch; too late to fix 2.8 :(. If you can, use trunk or the 2.9 branch instead. Otherwise, passing -mattr=-avx to llc should do the trick. -Eli > On Mar 18, 2011, at 6:50 PM, Eli Friedman wrote: > >> On Fri, Mar 18, 2011 at 2:56 PM, Nicolas Ojeda Bar

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define internal fastcc i64 @f.1() { > entry: >

On Mon, Aug 15, 2011 at 9:01 AM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed > to work, but I was wondering if anything can go wrong if the structured types are very large... It should work; the

Hi, Is this correct behaviour? test.ll: declare {} @__ex__print_int(i64) define i32 @main() { entry: %0 = call i64 @f.1() %1 = call {} @__ex__print_int(i64 %0) ret i32 0 } define internal fastcc i64 @f.1() { entry: ret i64 7 } > opt -std-compile-opts test.ll -S ; ModuleID = 'test.ll' define i32 @main() noreturn nounwind { entry: tail call void @llvm.trap()

Hi Paul, On 2009-12-04, at 09:34, Paul Melis wrote: > I hope you don't mind me sending this mail directly to you (instead of to llvm-dev), but you seem to be the expert on LLVM's GC support :) If you'd rather have me send to llvm-dev, please say so. You'll reach a wider audience with the list, though I haven't been able to keep up with it lately. > I'm trying to

On Sat, Sep 25, 2010 at 10:51 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > I didn't have unions in mind - indeed you need some kind of static > information in such a case. The GC infrastructure in LLVM having so little > love, I think it is good if you can improve it in any ways, as well as > defining new interfaces. So the patch is OK then? All it does

On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote: >> >> >> Many languages support the notion of a "value type". Value types are >> always passed by value, unlike reference types which are always passed by >>

On 04/29/10 21:27, Talin wrote: > On Wed, Apr 28, 2010 at 12:16 PM, Paul Melis > <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: > > On 04/27/10 00:20, Talin wrote: >> On Mon, Apr 26, 2010 at 12:44 AM, Paul Melis >> <llvm at assumetheposition.nl <mailto:llvm at assumetheposition.nl>> wrote: >> >>

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the

On 02/24/2014 12:45 AM, Andrew Trick wrote: > > On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/14/2014 05:55 PM, Philip Reames wrote: >>> Splitting out a conversation which started in "make DataLayout a >>> mandatory part of Module" since the

FAIL: /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20- GcrootAttribute.c Failed with exit(1) at line 3 while running: /Volumes/mrs5/Packages/llvm-2/bin/llvm-gcc -emit-llvm - S -emit-llvm /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20- GcrootAttribute.c -o - | llvm-as llvm-as: assembly parsed, but does not verify as correct! Enclosing function does not specify a collector algorithm.