Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] in personality, why is landingpad null?"
2013 Mar 31
1
[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
2013 Oct 17
4
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
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
2013 Mar 31
2
[LLVMdev] landingpad catch types not making it to Dwarf tables
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
2013 Oct 17
0
[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
2016 Sep 30
0
setjmp/longjmp and volatile stores, but non-volatile loads
On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be>
wrote:
> Reid Kleckner wrote:
> > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev
> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > model. In order to ensure that changes performed in a try/setjmp==0
> > block survive
2013 Mar 31
0
[LLVMdev] custom landingpad data, not dwarf encoded clauses?
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
2013 Oct 18
0
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
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
2013 Mar 31
2
[LLVMdev] custom landingpad data, not dwarf encoded clauses?
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
2012 Jan 11
1
[LLVMdev] landingpad instruction documentation is vague
On 01/11/2012 02:37, Duncan Sands wrote:
>> 1. What happens when actual exception type isn't listed in catch or
>> filter clauses? Does it still return the corresponding structure like if
>> it was listed? Or behavior is undefined?
> if it doesn't match a clause then the exception continues to be unwound.
> Note that you can match a catch clause without being equal
2014 Nov 10
2
[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR
Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev
in the first place...
---
Based on code review discussion from John, he thinks filter expressions
should be emitted into the body of the function with the try, rather than
being outlined by the frontend.
Instead of having the frontend create filter functions, we would use labels
in place of typeinfo. The IR would look
2013 Apr 25
4
[LLVMdev] trouble understanding value in dwarf exception mechanism
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.
2014 Nov 13
2
[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR
Hi Reid,
I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood.
I’m still trying to get up to speed on what is and is
2015 Dec 02
2
Support token type in struct for landingpad
Hi David,
Sorry to bother you, but I would like to get some suggestions on your recent work of token type.
I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid
2015 Feb 03
2
[LLVMdev] RFC: Replace __cxa_begin_catch/__cxa_end_catch with intrinsics
> On Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote:
> I actually like the unified intrinsic approach here. The backend already has to know things about the personality function. Until recently we would assume that the personality function wants an Itanium LSDA, for example, and dump that out into a target-specific section. Now on Windows we look at the personality
2013 Nov 04
0
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
But the incoming value from the landing pad will always be null, won't it?
If so, just iterate through the predecessors and add the terminator as the
incoming value if it's an invoke instruction and add the null value it's
not.
Won't that work?
On Mon, Nov 4, 2013 at 2:22 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote:
> On 03/11/13 12:16, Henrique Santos wrote:
2013 Oct 18
0
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
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
2013 Oct 18
2
[LLVMdev] post-link Dwarf information appears wrong, works in JIT
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
2013 Nov 03
1
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
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,
2013 Nov 04
3
[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"
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
2012 Jan 11
0
[LLVMdev] landingpad instruction documentation is vague
On Jan 11, 2012, at 3:15 AM, 陳韋任 wrote:
> On Wed, Jan 11, 2012 at 11:37:50AM +0100, Duncan Sands wrote:
>> Hi Yuri,
>>
>>> I am new to the landingpad (which is relatively new too).
>>> Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some
>>> questions open:
>>>
>>> 1. What happens when actual exception type