llvm dev - Apr 2013 - [LLVMdev] object file/linking is missing my exception handlers

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 just missing some option to generate the Dwarf tables, but
I can't figure out what it is. For the JIT version I set
JITExceptionHandling and JITEmitDebugInfo on TargetOptions.

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130411/397f99a5/attachment.sig>

Hi,

On 11/04/13 06:06, edA-qa mort-ora-y wrote:
> 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.
you will get this if no catch clauses match (eg because there are no catch
clauses, perhaps because you only have cleanups).  Maybe the JIT wraps the
program in a big catch-all clause?  That would cause cleanups to run, and
would explain things if you don't have any catch clauses and instead do all
the work in cleanups.
> I produce my object file using TargetMachine::addPassesToEmitFile and
> then I link my resulting files with:
Are you using standard dwarf tables, or something of your own invention
(as discussed in a previous email)?
>
> gcc -o prog input.o -fexceptions
This just calls the linker, the -fexceptions option will be ignored.  In any
case, the big question is whether the exception table is in input.o already or
not.  You can disassemble it and take a look.
> I'm sure I'm just missing some option to generate the Dwarf tables,
but
> I can't figure out what it is. For the JIT version I set
> JITExceptionHandling and JITEmitDebugInfo on TargetOptions.
You don't have to do anything AFAIK: by default the code generators will
produce an exception table.

Probably you should send in your IR and the .o file.

Ciao, Duncan.

On 11/04/13 15:38, Duncan Sands wrote:
> you will get this if no catch clauses match (eg because there are no catch
> clauses, perhaps because you only have cleanups).  Maybe the JIT wraps the
> program in a big catch-all clause?  That would cause cleanups to run, and
I wrap the whole program in a catch-clause within the LLVM-IR itself.

I'm using the standard dwarf tables.
> case, the big question is whether the exception table is in input.o
> already or
I'm not sure what to look for. If I do a a 'readelf' on the file
there
are a few 'GCC_except_table_' blocks.
> Probably you should send in your IR and the .o file.
I've attached them (they are quite small, so hopefully okay for the
list).  I'm note sure about my support functions though, so my code for
the test_throw() function is below. It doesn't get to the personality
function so I won't post that.

extern "C" void test_throw()
{
	_Unwind_Exception * ue
static_cast<_Unwind_Exception*>(malloc(sizeof(_Unwind_Exception)));
	ue->exception_cleanup = leaf_cleanup_exception;
	ue->exception_class = leaf_exception_class;
	ue->private_1 = 123;
	ue->private_2 = 456;
	
	auto code = _Unwind_RaiseException( ue );
	//code == URC_END_OF_STACK
	//trace result/abort
}



-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: basic.o
Type: application/x-object
Size: 3240 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130411/b43d26a8/attachment.o>
-------------- next part --------------
; ModuleID = 'wrapper'

define i32 @add_integer(i32, i32) {
entry:
  %2 = add i32 %0, %1
  ret i32 %2
}

define i32 @sub_integer(i32, i32) {
entry:
  %2 = sub i32 %0, %1
  ret i32 %2
}

define i32 @div_integer(i32, i32) {
entry:
  %2 = sdiv i32 %0, %1
  ret i32 %2
}

define i32 @mul_integer(i32, i32) {
entry:
  %2 = mul i32 %0, %1
  ret i32 %2
}

define i32 @neg_integer(i32) {
entry:
  %1 = sub i32 0, %0
  ret i32 %1
}

define i1 @eq_integer(i32, i32) {
entry:
  %2 = icmp eq i32 %0, %1
  ret i1 %2
}

define i1 @lt_integer(i32, i32) {
entry:
  %2 = icmp slt i32 %0, %1
  ret i1 %2
}

define i1 @gt_integer(i32, i32) {
entry:
  %2 = icmp sgt i32 %0, %1
  ret i1 %2
}

define double @add_float(double, double) {
entry:
  %2 = fadd double %0, %1
  ret double %2
}

define double @sub_float(double, double) {
entry:
  %2 = fsub double %0, %1
  ret double %2
}

define double @div_float(double, double) {
entry:
  %2 = fdiv double %0, %1
  ret double %2
}

define double @mul_float(double, double) {
entry:
  %2 = fmul double %0, %1
  ret double %2
}

define double @neg_float(double) {
entry:
  %1 = fsub double 0.000000e+00, %0
  ret double %1
}

declare void @trace_integer(i32)

declare void @trace_float(double)

declare i8* @malloc(i64)

declare void @free(i8*)

define void @_void_destructor(i8*) {
entry:
  ret void
}

declare i32 @leaf_exception_personality(i32, i32, i64, i8*, i8*)

declare i8* @count_malloc(i64)

declare void @count_free(i8*)

declare void @_duplicate_release_shared()

declare void @_uncaught_exception(i8*)

declare void @_Unwind_Resume(i8*)

define void @_entry() {
entry:
  %_return_path = alloca i1
  store i1 false, i1* %_return_path
  %_exception = alloca { i8*, i32 }
  invoke void @test_throw()
          to label %post_call_4 unwind label %throw_2

func_ret_0:                                       ; preds = %block_1, %block_1,
%post_call_5, %post_call_4
  ret void

block_1:                                          ; preds = %post_call_5,
%post_call_4
  %0 = load i1* %_return_path
  br i1 %0, label %func_ret_0, label %func_ret_0

throw_2:                                          ; preds = %throw_cont_3,
%entry
  %1 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, i8*, i8*)*
@leaf_exception_personality
          catch i8* null
  store { i8*, i32 } %1, { i8*, i32 }* %_exception
  br label %throw_cont_3

throw_cont_3:                                     ; preds = %throw_2
  invoke void @trace_integer(i32 1)
          to label %post_call_5 unwind label %throw_2

post_call_4:                                      ; preds = %entry
  %2 = load i1* %_return_path
  br i1 %2, label %func_ret_0, label %block_1

post_call_5:                                      ; preds = %throw_cont_3
  %3 = load i1* %_return_path
  br i1 %3, label %func_ret_0, label %block_1
}

declare void @test_throw()

define void @main() {
entry:
  invoke void @_entry()
          to label %end unwind label %catch

catch:                                            ; preds = %entry
  %0 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, i8*, i8*)*
@leaf_exception_personality
          catch i8* null
  %1 = extractvalue { i8*, i32 } %0, 0
  call void @_uncaught_exception(i8* %1)
  br label %end

end:                                              ; preds = %catch, %entry
  ret void
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130411/b43d26a8/attachment.sig>

I can confirm now that my personality handler is invoked (I call
setHasUWTable on the functions now, but I'm not sure if that was the
difference).  In any case it appears the behaviour of the
tables/handling is slightly different between the JIT and GCC linked.
I'm trying to figure out what this is now.

On 11/04/13 06:06, edA-qa mort-ora-y wrote:
> 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 just missing some option to generate the Dwarf tables,
but
> I can't figure out what it is. For the JIT version I set
> JITExceptionHandling and JITEmitDebugInfo on TargetOptions.
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130412/72fcd800/attachment.sig>

In appears, as additional error I had, that the JIT is totally okay with
calling _Unwind_Resume on an exception which has already been handled.
When this is done it behaves as rethrowing the same exception (it
seems). In the GCC/ELF executable this results in a segmentation fault.

So it just appears in all the JIT handling of exceptions is rather
different, perhaps more lenient than exec code. This is very strange of
course since my program calling the JIT is linked using the same GCC,
thus one would assume the _Unwind_ functions are exactly the same.
Perhaps just the EH table information is just layed out differently.


On 12/04/13 06:00, edA-qa mort-ora-y wrote:
> I can confirm now that my personality handler is invoked (I call
> setHasUWTable on the functions now, but I'm not sure if that was the
> difference).  In any case it appears the behaviour of the
> tables/handling is slightly different between the JIT and GCC linked.
> I'm trying to figure out what this is now.

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130412/d7ea9595/attachment.sig>