Exceptions not working even with DISABLE_EXCEPTION_CATCHING=0

[ekkxl]

I'm working on developing a programming language, which directly generates LLVM files which I compile with emscripten to generate JS files. Everything works except exceptions which are not being caught properly. I'm building with -fexception and -s DISABLE_EXCEPTION_CATCHING=0. More strange is I also have a runtime library written in C++, and exceptions are being caught there. So an example stack trace

1. some_function_that_throws
2. some_function_that_catches
3. cpp_function_that_catches

The exception should be caught by 2 but is being caught by 3. Same problem with WASM on or off. Here's a snippet of my LLVM assembly:

	invoke void @K_throw( %t_struct %t_16 ) to label %label_7 unwind label %label_6
label_7:
	; some code
label_6:
	%t_49 = landingpad { i8*, i32 } cleanup
	store { i8*, i32 } %t_49, { i8*, i32 }* %exceptionInfo
	%t_49_exception_value = extractvalue { i8*, i32 } %t_49, 0
	store i8* %t_49_exception_value, %t_exception* %exception
	; more code

So in this case K_throw will throw, but it's not being caught by the landingpad, Looking at the generated JS code with WASM off, I see that it's not even generating an invoke_XXX call for the call to K_throw.

I've tried compiling the C++ runtime files with -S emit-llvm and compared that to the LLVM code I'm generated, and I don't see any significant difference in the way I'm defining functions, personality functions, landing pads, etc.

All of this code worked perfectly under an old version of emscripten (1.37.21). I updated to the latest version (2.0.32) and exceptions stopped working without any changes to my files.

[kripken]

One possible issue is that you need to pass that flag at both compile and link times, since it affects codegen at both times.

If that's not it, bisection might be a quick way to find when things changed (even with a big range like 1.37.21-2.0.32, bisection would do it in logarithmic time).

[ekkxl]

The flags are being passed at both compile and link time.

I can try bisection, but it will probably take a while as I'll also need to build my dependencies (like Boost) and my experience is I'll need to fiddle with build settings to get them working with different versions.

Any other ideas to try?

[kripken]

Hmm, another way might be to build something simpler and see that that works. Just your main() function throwing and catching an exception, for example. Then you can disassemble that object file to see that it was emitted properly (you should see invoke* calls with that flag).

[ekkxl]

I've managed to strip it down to the following case

main.cpp

#include <stdio.h>

extern "C"
{
	void test_ll();
	void test_print()
	{
		printf("test\n");
	}
	void test_throw()
	{
		throw 3;
	}
}

int main( int argc, char **argv )
{
	try
	{
		test_ll();
	}
	catch( ... )
	{
		printf("catch in main\n");
	}
}

test.ll

target datalayout = "e-p:32:32-i64:64-v128:32:128-n32-S128"
target triple = "wasm32-unknown-emscripten"

declare i32 @__gxx_personality_v0(...)
declare i8* @__cxa_begin_catch(i8*)
declare void @__cxa_end_catch()

declare void @test_print()
declare void @test_throw()

define void @test_ll() personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)
{
	call void @test_print()
	invoke void @test_throw() to label %label_1 unwind label %label_2
label_1:
	unreachable
label_2:
	%t1 = landingpad { i8*, i32 } cleanup
	%t1_exception_value = extractvalue { i8*, i32 } %t1, 0
	call void @test_print()
	ret void
}

build with

em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -o main.bc main.cpp
em++ -s DISABLE_EXCEPTION_CATCHING=0 -s WASM=0 -fexceptions -g -O0 -o test.js main.bc test.ll

Running it with node, it outputs "test catch in main", instead of the expected "test test"

Here's the output js for test_ll:

function test_ll() {
  test_print();
  test_throw();
  abort();
 }

As you can see, it's not producing an invoke_XXX call for test_throw.

[kripken]

As you can see, it's not producing an invoke_XXX call for test_throw.

Invokes are emitted for catching, not throwing.

I do see invokes emitted in compiled code, for example here is main after I run your commands:

 function main($0, $1) {
  $0 = $0 | 0;
  $1 = $1 | 0;
  var $4 = 0, $10 = 0, $20 = 0, $21 = 0, $29 = 0, $38 = 0, $41 = 0, $42 = 0, $47 = 0;
  $4 = __stack_pointer - 32 | 0;
  __stack_pointer = $4;
  HEAP32[($4 + 28 | 0) >> 2] = 0;
  HEAP32[($4 + 24 | 0) >> 2] = $0;
  HEAP32[($4 + 20 | 0) >> 2] = $1;
  HEAP32[(0 + 2272 | 0) >> 2] = 0;
  invoke_v(1 | 0);

That leaves test_ll does not have invokes. I assume that is because you provide LLVM IR for it, and that LLVM IR does not have exceptions enabled - that should be declared. Indeed, running

./em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -o main.bc test.ll

emits

 (func $0
  (call $fimport$0)
  (call $fimport$1)
  (unreachable)
 )

with no invokes, even though the code has invokes and landing pads.

I'm not sure how to declare exceptions support in LLVM IR. @aheejin ?

[ekkxl]

If I compile main.cpp to LLVM IR and link that using

em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -S -emit-llvm -o main.ll main.cpp
em++ -s DISABLE_EXCEPTION_CATCHING=0 -s WASM=0 -fexceptions -g -O0 -o test.js main.ll test.ll

Then main() calls test_ll() directly without an invoke, so the exception is completey uncaught:

function main($0, $1) {
  $0 = $0 | 0;
  $1 = $1 | 0;
  var $4 = 0, $6 = 0;
  $4 = __stack_pointer - 32 | 0;
  __stack_pointer = $4;
  HEAP32[($4 + 28 | 0) >> 2] = 0;
  HEAP32[($4 + 24 | 0) >> 2] = $0;
  HEAP32[($4 + 20 | 0) >> 2] = $1;
  test_ll();
  $6 = HEAP32[($4 + 28 | 0) >> 2] | 0;
  __stack_pointer = $4 + 32 | 0;
  return $6 | 0;
 }

If I compile test.ll to bitcode first and link that, using

em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -o main.bc main.cpp
em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -o test.bc test.ll
em++ -s DISABLE_EXCEPTION_CATCHING=0 -s WASM=0 -fexceptions -g -O0 -o test.js main.bc test.bc

I get the same behavior as linking test.ll directly, ie no invokes in test_ll() and the exception is caught in main instead of test_ll.

[ekkxl]

Works in 2.0.8, fails in 2.0.9

Could 511bd90 be related?

[aheejin]

-emit-llvm emits bc/ll files before running the Wasm backend. The transformation pass that adds invoke_s runs as a part of the Wasm backend, so it will not appear in the bc/ll files emitted using -emit-llvm. The only way you can see invoke_s in ll files is to run that pass individually using opt, but I doubt if normal users would ever need to do it.

So what you see in the ll files is not a bug. If you see a case where an exception is not caught when it is supposed to be, that could be a bug, so if you have such reproducer, please let us know.

By the way, I tried to fill in test_ll in your example, compile the program, and run it. It seems to run correctly.

• main.cpp:

#include <stdio.h>

extern "C" {
void test_ll() {
  printf("test_ll\n");
  throw 3;
}
void test_print() { printf("test\n"); }
void test_throw() { throw 3; }
}

int main(int argc, char **argv) {
  try {
    test_ll();
  } catch (...) {
    printf("catch in main\n");
  }
}

$ em++ main.cpp -s DISABLE_EXCEPTION_CATCHING=0 -o main.js
$ node main.js
test_ll
catch in main

[ekkxl]

First failing emsdk build is 5b8aafeb98dfdea63de7a4665e9b61347430dd0a, so it appears 511bd90 is the cause.

[ekkxl]

The only way you can see invoke_s in ll files is to run that pass individually using opt, but I doubt if normal users would ever need to do it.

I'm not expecting to see invoke_XXX in the ll files. I'm expecting to see invoke_XXX in the final js or wasm file, and it's not there.

So what you see in the ll files is not a bug. If you see a case where an exception is not caught when it is supposed to be, that could be a bug, so if you have such reproducer, please let us know.

The example I gave should catch an error in the test_ll(), but it's caught in main() instead.

By the way, I tried to fill in test_ll in your example, compile the program, and run it. It seems to run correctly.

That's not quite correct, perhaps you misread my example, there are two files: main.cpp and test.ll that are compiled and linked together (test.ll is not the output of -emit-llvm). This would be closer in a single cpp file:

#include <stdio.h>

extern "C" {
void test_ll() {
  try {
    test_throw();
  } catch(...) {
    test_print();
  }
}
void test_print() { printf("test\n"); }
void test_throw() { throw 3; }
}

int main(int argc, char **argv) {
  try {
    test_ll();
  } catch (...) {
    printf("catch in main\n");
  }
}

Building and running that prints out "test" as expected, but the problem seems to be that when compiling ll files directly, emscripten is not passing along the correct options to enable exceptions. So if everything is in a single cpp file it will be fine. If you instead compile it to an ll file first, the build and run that, you'll get an uncaught exception:

>em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -c -S -emit-llvm -o new_main.ll new_main.cpp
>em++ -s DISABLE_EXCEPTION_CATCHING=0 -fexceptions -g -O0 -o new_main.js new_main.ll
>node new_main.js
exception thrown: 5246008

I would believe that

emcc++ (options) -o foo.js foo.cpp

should be equivalent to

emcc++ (options) -c -S -emit-llvm foo.ll foo.cpp
emcc++ (options) -o foo.js foo.ll

in all cases, but it's not here.

[aheejin]

Do we support compiling ll/bc files directly?
Also cc @sbc100 for the #12705 question.

[sbc100]

It appears that we do yes. More specifically, if clang supports it then I think its good that we support it too.

[sbc100]

emcc++ (options) -o foo.o foo.cpp

should be equivalent to

emcc++ (options) -c -S -emit-llvm foo.ll foo.cpp
emcc++ (options) -o foo.o foo.ll

in all cases, but it's not here.

Are you expecting foo.o to be and object file here? If so, don't you need a -c in both commands above?

[ekkxl]

My mistake, I meant .js. I've edited my other comment.

[sbc100]

My mistake, I meant .js. I've edited my other comment.

In that case yes, I believe those should produce the same results.