similar to: [LLVMdev] GenericValue changes from 1.8 to 2.0

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

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

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 likely to > be supporting anything other than C and C++

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

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

Hi all, I've now got my LLVM-based model checker more or less working, but I'm seeing something a bit strange happening. As you may remember, I started with the lli code and extended it considerably. I have retained something that looks vaguely like the original ExecutionContext stack, though I now have one stack per thread, and the whole data structure is implemented with custom

Hmm... looks like my LLVM build script only built debug versions of the tools, not release versions. I'm investigating, I didn't change anything that should have caused that. [s] On Apr 28, 2009, at 4:56 PM, Bill Wendling wrote: > On Tue, Apr 28, 2009 at 4:43 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> OK, that got much further, but I'm now

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

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 >

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

(My script does both of those -- the debug build worked (I think), but the release build fails) [s] On Apr 28, 2009, at 5:19 PM, Bill Wendling wrote: > 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

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

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 using the jitter for some things that need to be fast

OK, that got much further, but I'm now seeing another problem which may (or may not) be related. Building my own code (my model checker), it builds libraries fine, then within tools (I'm using a fairly standard LLVM build environment here), I am seeing the error *** llvm-config doesn't exist - rebuilding it followed by a make: Entering an unknown directory which is

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

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 Folks, I'm having some difficulties getting LLVM to build and work correctly on CENTOS 5.3. This is basically tracked down easily enough to CENTOS using GCC 4.1.x by default, which is known-buggy and known not to work with LLVM -- I was getting the well-known problem with aborts due to a non-empty symbol table. I have installed the gcc43 package via yum (I'm trying to stick

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

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 matter which really), yielding a result in bytes, what is the known-safe way to do this? I notice that doing something like struct thingy { ... some stuff ... }; ... printf("Size = %d",

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