similar to: [LLVMdev] understanding of getelementptr with a const string

I'm working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

I'm having an issue where a certain set of types and insert/extractvalue are producing the incorrect values. It appears as though extractvalue getting my sub-structure is not getting the correct data. I have these types: %outer = type { i32, %inner, i1 } %inner = type { double, i32 } The trouble is that when I have a value of type %outer then proceed to extract the components of the

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a

Yes, but why is it even copying the memory?  It already has a pointer which it can cast and load from -- and does so in other scenarios. I'm wondering whether this copying is somehow required and I'm missing something, or it's just an artifact of the clang emitter. That is, could it not omit the memcpy and cast the original variable? On 18/04/18 19:43, Krzysztof Parzyszek via

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64

I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this difference in alignment and

Something must be wrong with the Function Type. Try to debug into runFunction to see which if condition fails. Just a guess, if this is on 64 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

On 17/10/13 23:57, Bill Wendling wrote: > There shouldn't be any special linker flags you need to use. If > you're getting segfaults, it's probably trying to access the data at > an invalid location or something. Make sure that your EH table is > properly aligned. You might want to hand calculate the values to make > sure that they're correct. What platform are you

It sounds like your DataLayout may not match clang's for x86_64-linux. What does it say about the alignment of i64? On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` > is returning `12`. `getStructLayout` also gives an `4` offset for the > second

Yes, I understand that as well (it's what I'm trying to recreate in my language now). I'm really wondering why it does the copy, since from what I can tell it could just as easily cast the original value and do the load without the memcpy operation. That is, the question is about the memcpy and extra alloca -- I understand what it's doing, just not why it's doing it this way.

I'm having a problem with my code generating empty lines and it appears to be the CLib `open` function generating an empty line when used within the JIT-VM. If I compile my program to an exe file it doesn't happen. I also have a lot of other code running in the VM without this problem, it's somehow particular to `open`. A chunk of my IR that calls `open`: defer_body_26:

I'm trying to get MCJIT working but I get the following errors: Full-featured argument passing not supported yet! UNREACHABLE executed at MCJIT.cpp:322! I'm sure the first one will be a problem, but the second one prevents me from testing anything. I don't know how to fix the problem. My code works when using the non-MC JIT, and I added to my EngineBuilder: .setUseMCJIT(true)

Does this help? http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On 11 Nov 2012, at 10:52, edA-qa mort-ora-y <eda-qa at disemia.com<mailto:eda-qa at disemia.com>> wrote: Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get

I believe the memcpy is there just as a consequence of Clang's design - different parts of the compiler own different pieces of this, so in some sense one hand doesn't see what the other is doing. Part of it is "create an argument" (memcpying the local variable into an unnamed value) and then the next part is "oh, but that argument gets passed in registers, so decompose it

I'm having trouble figuring out what the error "Instruction does not dominate all uses!" means. I'm trying to construct a call to a function with two parameters. The printed IR, with error, looks like this: define i32 @add(i32, i32) { EntryBlock: %2 = add i32 %0, %1 ret i32 %2 } define i32 @eval_expr() { EntryBlock: ret i32 <badref> } Instruction does not dominate

I'm having trouble understanding the value in the way exceptions are handled on Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads.

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

On 14/04/13 19:50, edA-qa mort-ora-y wrote: > I don't know if there is an explicit clone method, but you could do the > printing and then parse it again. That would effectively create a clone > of the object. It appears the "llvm" namespace has several Clone functions. Thus you should be able to do what I suggested: Clone the function, run the original through the