similar to: [LLVMdev] lli threads

Hi all, Is there any way to support calling external libraries from interpreted code (*not* JITted code) within lli? I am looking at the external functions implementation, and it seems just to wrap back onto its own library, looking up lli_X_... prefixed functions. It would (for obvious reasons) be incredibly useful not to be restricted to the (tiny) set of supplied functions. Thank you in

On Wed, 25 Oct 2006, Sarah Thompson wrote: > Is there any way to support calling external libraries from interpreted > code (*not* JITted code) within lli? Sure. > I am looking at the external functions implementation, and it seems just > to wrap back onto its own library, looking up lli_X_... prefixed > functions. It would (for obvious reasons) be incredibly useful not to be >

On Thu, 26 Oct 2006, Sarah Thompson wrote: > Chris Lattner wrote: >> 3. Best: Find a "foreign function interface" library, and use that to >> interface to native code. >> > This is the only option that's really usable, unfortunately, because I > have no control over what code some potential user might want to model > check. Ok. > I was wondering

Hi Sarah, On Fri, 2007-03-23 at 15:11 -0700, Sarah Thompson wrote: > I'll almost certainly come along, possibly with one or two other NASA > people. Great! If/when you know their names, have them drop me a line here. I'd rather put down names than "Sarah+2". Thanks. > I could give a talk on our work using LLVM to support model > checking, symbolic execution and

Chris Lattner wrote: > On Tue, 17 Jul 2007, Sarah Thompson wrote: > > >> Do I understand correctly that there is nothing that the current gcc >> front end generates that wouldn't fit an old-style GenericValue? I'm >> wondering if this might be an interim approach that would avoid me >> needing to rewrite huge amounts of code, and since we're not

Check out http://nondot.org/sabre/LLVMNotes -Chris http://nondot.org/sabre http://llvm.org On Jul 27, 2007, at 12:00 PM, Sarah Thompson <thompson at email.arc.nasa.gov > wrote: > Hi folks, > > Assuming that I'm writing a pass and that for bizarre reasons I need > to > programmatically do the equivalent of a C/C++ sizeof on a Value (or a > Type, it doesn't

I can't make it on the 22nd, but I will be there if it's on the 29th. Ryan Brown On 3/23/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Hi Sarah, > > On Fri, 2007-03-23 at 15:11 -0700, Sarah Thompson wrote: > > I'll almost certainly come along, possibly with one or two other NASA > > people. > > Great! If/when you know their names, have them

I'll almost certainly come along, possibly with one or two other NASA people. I could give a talk on our work using LLVM to support model checking, symbolic execution and static analysis if anyone is interested. Sarah Thompson RSE/6G, NASA Ames >

Sarah Thompson wrote: > Chris Lattner wrote: > >> On Tue, 17 Jul 2007, Sarah Thompson wrote: >> >> >> >>> Do I understand correctly that there is nothing that the current gcc >>> front end generates that wouldn't fit an old-style GenericValue? I'm >>> wondering if this might be an interim approach that would avoid me

Chris Lattner wrote: > > The JIT has a superset of this functionality. However, if there is JIT > support for the host that you are interested in, you shouldn't have to use > the interpreter at all. > > For interpreting, yes, but model checking is weirder so it's greatly beneficial to be able to heavily hack an interpreter. >> I can't really move to using

Reid Spencer wrote: > Hi Sarah, > > On Tue, 2007-07-17 at 10:05 -0700, Sarah Thompson wrote: > >> Hi all, >> >> I've been quiet for a while, but I'm liable to be less so now that I'm >> starting on porting our model checker from LLVM 1.8 to 2.0. >> > > We missed you! :) > > Yes, apologies again for not making the

Hi Sarah, On Tue, 2007-07-17 at 10:05 -0700, Sarah Thompson wrote: > Hi all, > > I've been quiet for a while, but I'm liable to be less so now that I'm > starting on porting our model checker from LLVM 1.8 to 2.0. We missed you! :) > One thing > that is puzzling me somewhat are the changes made to the GenericValue > union, which is now a struct. I

>>> I can't really move to using the JIT entirely because I want to replace >>> the memory model with something that supports backtracking -- this is >>> doable (fairly) straightforwardly with the interpreter, but it would >>> require some very complicated transformations to the code in order to do >>> this within the JIT environment, and it would

Chris Lattner wrote: > 3. Best: Find a "foreign function interface" library, and use that to > interface to native code. > This is the only option that's really usable, unfortunately, because I have no control over what code some potential user might want to model check. I was wondering whether there might be anything in the JIT support that could be reused for

Hi folks, I'm currently extending my model checker to collect coverage information, and as part of this I'm finding a need to get a more friendly version of munged C++ identifiers than the name used by the linker. For example, though internally, something like '_Z7thread1Pv' is fine as an identifier, I'd like to be able to give the user something more readable. Since

Sarah Thompson wrote: > Hi, > > As some of you may remember, I'm implementing an LLVM-based model > checker. I'm doing something a little odd, in that mostly I'm using the > interpreter (currently a hacked version of lli with threads) for most > things because I need to hook into lots of stuff that would be difficult > to manage otherwise, but I'm also

Just to give closure here, I eventually gave up, built an Ubuntu 9 VMWare image which uses gcc 4.3.2 by default, installed Eclipse Ganymede and various other tools, then built LLVM 2.5 and my own code. It all ran fine. There is clearly something broken in the CentOS gcc43 package. Definitely one to avoid. [s] On Apr 28, 2009, at 5:40 PM, Sarah Thompson wrote: > (My script does both

Hi all, I've been quiet for a while, but I'm liable to be less so now that I'm starting on porting our model checker from LLVM 1.8 to 2.0. One thing that is puzzling me somewhat are the changes made to the GenericValue union, which is now a struct. I haven't found any mention of this on the llvm site or in the archives, so it may be that I am the only one who cares about it

We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on the "make" command line or --enable-optimized during configuration. -bw On Tue, Apr 28, 2009 at 5:12 PM, Sarah Thompson <sarah at findatlantis.com> wrote: > Hmm... looks like my LLVM build script only built debug versions of > the tools, not release versions. I'm investigating, I didn't change

Hi all, I am currently working on a static analysis aimed at integer arithmetic overflow/underflow detection. We are attempting to build a sound abstract domain (based on Cousot & Cousot-style abstract interpretation), but practically speaking this really requires the ability to figure out the word size and signedness of values in the intermediate representation. I'm well aware