similar to: [LLVMdev] How to read memory data througn adress of unsigned long

On Fri, Mar 25, 2011 at 8:53 PM, Michael.Kang <blackfin.kang at gmail.com> wrote: > I have a value of long type and like to get the data at the adress in the value: > > ################# > unsigned long v = 0xc0008000 > Value* addr = ConstantInt::get(getIntegerType(64), v) > #################### > > Then I try to use LoadInstr to get a load instruction of ir as the

Now I have an address that present in a unsigned long address like the following format: Value* addr = CONST(0xc0008000) But I do not know how to read the data from the above addr varaible. I tried the following three kind of code: 1. Code: Value* addr = CONST(0xc0008000); Value* data = new LoadInst(addr, "", false, bb); Error: Segmentation fault 2. Code(

Hi Michael, > Now I have an address that present in a unsigned long address like the > following format: > Value* addr = CONST(0xc0008000) what is the type of addr? For that matter, what is CONST - what does it do? Ciao, Duncan. > > But I do not know how to read the data from the above addr varaible. I > tried the following three kind of code: > 1. Code: >

Greetings, LLVM wizards. I am using clang to compile a C++ module, and an ExecutionEngine (MCJIT) to execute a function it defines. That works (or pretends to). However, if I call the module's constructors first: exec_engine->runStaticConstructorsDestructors(false); exec_engine->runFunctionAsMain(function, argvec, NULL); execution still works, but my program crashes when it exits, in

Dear All I'm making an instrumentation pass. The pass is supposed to modify the given IR in a specefic way. One of the required modifications is to insert a call to a function at a specific location. This is the signature of the called function: void myclass::foo(Function *f, BasicBlock* b) This function's prototype is in an foofile.h file in include/llvm And the function

On Alex's advice I am switching from MCJIT to the Orc API to compile and execute functions. Starting from the new clang-interpreter example in the source code (top of the tree!), I am able to execute my functions all right... as long as there are no constructors and destructors to call. My question: is there a simple way, with the Orc API, to run a module's constructors and destructors? I

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute the constructors straight away, rather than naming them and looking them up

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote: >

Hi all, I couldn't find any reasonable way to create the IntegerType that would match, say, intptr_t, that is the native word size of the machine I'm building on. More accurately defined, when compiling on a 64 bit Mac OS machine I want it to be Int64Ty, but if for example I'm using the "-arch i386" command line option on that machine during compilation, I want it to be

This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this

We try to use llvm to translate and generate the native code in parallel with multi-thread. But some various bugs will be triggered. We run the following code in multithread environment: ################## BasicBlock::Create(_CTX(), "dispatch", cpu->cur_func, 0); BranchInst::Create(bb_start, label_entry); cpu->exec_engine->getPointerToFunction ##################3 And cpu

I have created the function prototype with the following code: const uintmax_t methodNameSize = 1024; const char methodNameTemplate[] = "llvm.memcpy.p0i%llu.p0i%llu.i%llu"; char methodName[methodNameSize]; // Create the methodName. memset(methodName, 0, methodNameSize); sprintf(methodName, methodNameTemplate, dstSize, srcSize, lengthSize); // Search for the

So does that mean that LLVM can't lower automatically to 8-bit values? I tried defining 8-bit pointers in the subtarget using "p:8:8:8" but it asserts at line 566 of TargetData.cpp in the default case of TargetData::getIntPtrType() Is it difficult to add 8-bit support? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

On Thu, 2 Mar 2006, Vladimir Prus wrote: >>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from

On Sep 7, 2010, at 11:30 AM, F van der Meeren wrote: > > > Any ideas on what I am doing wrong here ? > Why not just use something like: const Type *ArgPtr = Type::getInt8PtrTy(Context); const Type *IntPtr = getTargetData().getIntPtrType(Context); and then: const Type *ArgTypes[3] = {ArgPtr, ArgPtr, IntPtr }; Intrinsic::getDeclaration(TheModule,

Thank you Evan, I added the return Type::Int8Ty to the switch statement to get it to work. I don't know if this can have other consequences, I haven't yet verified if the generated Legalized DAG is correct though. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 3:23 PM To:

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > So does that mean that LLVM can't lower automatically to 8-bit values? There is no inherent reason. LLVM should be able to lower to 8-bit values. It's probably a bug somewhere. In TargetLowering.h: bool isTypeLegal(MVT::ValueType VT) const { return !MVT::isExtendedVT(VT) && RegClassForVT[VT] !=

On May 14, 2008, at 10:43 AM, Alireza.Moshtaghi at microchip.com wrote: > In this thread I’m trying to merge two email threads into one, > because both discuss the same problem that’s troubling us and I > would like to reach a conclusion on what would be the best approach. > To minimize the size of this thread I only mention the subject of > the other two threads: > (1)

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,