similar to: [LLVMdev] post-link Dwarf information appears wrong, works in JIT

On Oct 17, 2013, at 11:35 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > 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

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

I added several more clauses to see the result. It looks like the landing pad information is generated correctly: I get the correct number of action records, each record has a reasonable index into the type table (from 1 to 9). The encoded address increment in 4 however, which is unexpected since they are size 8 (in the JIT they increment by 8). Whatever is causing that may also be responsible for

On Oct 17, 2013, at 9:37 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > I added several more clauses to see the result. It looks like the > landing pad information is generated correctly: I get the correct number > of action records, each record has a reasonable index into the type > table (from 1 to 9). The encoded address increment in 4 however, which > is

I was having problems with my exception handling due to mixing PIC and non-PIC code into my executable. Now I'm confused as to how I'm supposed to do this correctly when I do have to mix different code types. The basic setup: - shared library which throws and catches exceptions, some exceptions leave it's library bounds - main executable which throws and catches exceptions, exceptions

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 =

On Oct 17, 2013, at 7:24 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > 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

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

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

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 am having some trouble getting my catch clauses to appear as expected in the dwarf exception tables. I have an instruction like this: %0 = landingpad i64 personality i32 (i32, i32, i64, i8*, i8*)* @leaf_exception_personality catch i8* inttoptr (i64 987 to i8*) catch i8* inttoptr (i64 2453 to i8*) In my exception handler I walk through the records. I always get the correct

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

In my language I have anonymous types (essentially tuples), and I have generated functions (like constructors) which are unique for these types. If the same type occurs in multiple modules however it should end up with only one definition being linked. Thus I need a way to give them the same name. The problem is that if I derive the name from what the type contains the length of that name is

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva > Sent: Wednesday, June 19, 2013 11:45 AM > To: edA-qa mort-ora-y > Cc: <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] How to deal with potentially unlimited count/length symbol names? > > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at

MCJIT::runFunction supports only main-style argument passing but not other cases like the JIT. These types of arguments will work: (int, char**, char**) (int, char**) (int) (void) The general case is not supported since it requires creating a small stub function, compiling and running it on the fly, supported by JIT but not MCJIT. However, with the supported calling sequences, you can probably

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

How would I go about getting a custom data format stored at the exception landing pads (the location _Unwind_GetLanguageSpecificData returns)? The Dwarf encoded format is not well suited for the type of exception handling I wish to do in my language. Will this be possible, or is exception handling mechanism so tightly tied to the Dwarf format that it would be extremely difficult? -- edA-qa

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.

This may sound weird, but what exactly is a FunctionType? That is, in terms of memory, or underlying value, what does the FunctionType actually represent. At first I though it might be a pointer, but it is not -- since you have to wrap a PointerType around it to use as such. Can a FunctionType value actually exist, or is strictly an abstract concept? In particular, can I actually directly define