similar to: [LLVMdev] custom landingpad data, not dwarf encoded clauses?

On 31/03/13 19:28, Duncan Sands wrote: >> 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. > I didn't understand the question, can you please be more explicit

Hi edA-qa mort-ora-y, On 31/03/13 16:28, edA-qa mort-ora-y wrote: > 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

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 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'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

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 have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm

I'm getting an error that I don't know how to fix. I've isolated the input as much as I easily can. I've attached the file that produces the problem. Just calling "llc err.ll -o err.s" generates the error. I'm going to try and isolate even further, but as I'm not sure what I'm looking for I don't know if I'll be successful. Does anybody know what this

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

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 03/11/13 12:16, Henrique Santos wrote: > You could try placing a phi node at "defer_block" with incoming value > "result" > when the incoming block is "entry", and do the same for "null" and > "landing". > Then, instead of loading "result", you load the value given by the newly > created phi. That seems like the

Hi, On 25/04/13 07:38, edA-qa mort-ora-y wrote: > 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

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've reduced the example down to a minimum. The error is quite perplexing since the IR appears fine. It is a nonsensical infinite loop now, but that shouldn't be a problem. declare i64 @leaf_exception_personality(i64, i32, i64, i8*, i8*) declare i8* @count_malloc(i64) define internal i8 @junk___init_module_get_args_3() #0 { entry: %_exception = alloca { i8*, i64 } %ignore0 = invoke

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

I've having a bit of a problem generating output that doesn't result in the "Instruction does not dominate all uses!". In my code it relates to exception handling and how I generate the blocks. I understand exactly why I get the message, but I'm unsure of how I can structure things to avoid the problem. In a rough pseudo-code, my blocks look like this: entry: store 0,

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

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