llvm dev - Aug 2011 - [LLVMdev] RFC: Exception Handling Rewrite

Bill,
         I suspect we're talking about two different aspects,
I think you are saying that there is an ability for the DWARF Actions  
Table
to contain multiple lists, including multiple filter lists - no  
disagreement
there,
I am saying that for any one landing-pad it might not make sense
for it to be able to have more than one filter list.


-Peter Lawrence.


On Aug 4, 2011, at 2:38 PM, Bill Wendling wrote:
> On Aug 4, 2011, at 2:03 PM, Peter Lawrence wrote:
>
>> Bill et al,
>>                 I haven't really thought this through (I've
never
>> been a fan of exception specifications),
>> but it seems that inlining functions that do have exception  
>> specifications, and hence filter
>> operands in their landing-pads, isn't so obvious...
>>
>> if  you want to  inline
>>
>> 	void foo () throw() { ... }		// empty throw() list means
"no-throw"
>>
>> into a function that does allow exceptions to be propagated out,  
>> then you'll have a hard time
>> combining their landing pads !
>>
>> it seems, at least on first thought, that having more than one  
>> filter list in a landing pad isn't
>> useful ?  (assuming the only way to get more than one is from  
>> inlining ?)
>>
> The exception tables are set up to allow for multiple exception  
> specifications per function. So if we inline a function with  
> exception spec of A, B, C into one with an exception spec of D, E  
> then it's totally doable. The table will look something like this:
>
>   A
>   B
>   C
>   0
>   D
>   E
>   0
>
> And the "action" part of the table will point to the correct  
> exception spec start (A or D) depending on what state the exception  
> is at a given time. (I.e., is it in a "resume" situation or
"catch"
> situation.)
>
> -bw
>

On Aug 4, 2011, at 2:58 PM, Peter Lawrence wrote:
> Bill,
>        I suspect we're talking about two different aspects,
> I think you are saying that there is an ability for the DWARF Actions Table
> to contain multiple lists, including multiple filter lists - no
disagreement
> there,
> I am saying that for any one landing-pad it might not make sense
> for it to be able to have more than one filter list.
> 
In general, it's not bad. But there is one problem, which your example
illustrates.

	void foo() throw() { /* ... */ }

When "foo()" is inlined into its caller, the resulting function's
EH table should be set up to disallow exceptions thrown for the inlined contents
of foo(). Our current scheme is to mark foo() as "nounwind" and make
it a normal "call" instruction. Some care will have to be taken during
inlining to keep the "no throwing" attribute around for the code that
cares about it.

-bw

Bill,
        I believe the empty-exception-specification example is a red- 
herring,
but that if you can construct an example where you think a landing-pad
requires multiple filter lists then I think we can then have a  
productive
conversation about it.

I believe we can only get multiple filter lists in a landing-pad if  
we attempt
to merge exception-regions, and since filters are only an outer-function
concept (not an inner try-statement concept) this can only come about
from function inlining.

so say we're considering inlining "void foo() throw(A) { ... }" 
into
"void bar() throw (B) {...  foo(); ... ; frob(); ...}"

if you attempt to merge the landing pad for these functions (perhaps
assuming it is going to be simple because there are no cleanups in  
either
function that would complicate things) then...

there has to be a filter for A that will terminate the program if A  
is thrown,
but you cannot terminate the program if exception A comes from frob()
since it has not exception specification.


my conclusion is that you can only merge landing-pads if they already
have *identical* filters, so multiple filter lists isn't  
mathematically possible.

thoughts ?
comments ?

-Peter Lawrence.



PS.  I believe the empty-exception-specification example is a
red-herring because I believe you are making the same mistake that
everyone does concerning "exception specifications", which is assuming
they imply compile time correct information --  like "const" is  
enforced at
compile time  --  which is false  (and why exception specifications  
are a
bad design).


__attribute__((nothrow))  <--- user guarantee that the function
does not throw, the compiler is free to optimize based on this
assertion, and if the program violates that guarantee then the
the program is "undefined" and can "do anything".

throw()                                  <--- not a user guarantee of  
anything,
rather a user requirement that the compiler generate runtime checking
code to enforce that no exception is propagated out.












On Aug 4, 2011, at 3:20 PM, Bill Wendling wrote:
> On Aug 4, 2011, at 2:58 PM, Peter Lawrence wrote:
>
>> Bill,
>>        I suspect we're talking about two different aspects,
>> I think you are saying that there is an ability for the DWARF  
>> Actions Table
>> to contain multiple lists, including multiple filter lists - no  
>> disagreement
>> there,
>> I am saying that for any one landing-pad it might not make sense
>> for it to be able to have more than one filter list.
>>
> In general, it's not bad. But there is one problem, which your  
> example illustrates.
>
> 	void foo() throw() { /* ... */ }
>
> When "foo()" is inlined into its caller, the resulting
function's
> EH table should be set up to disallow exceptions thrown for the  
> inlined contents of foo(). Our current scheme is to mark foo() as  
> "nounwind" and make it a normal "call" instruction.
Some care will
> have to be taken during inlining to keep the "no throwing"  
> attribute around for the code that cares about it.
>
> -bw
>