[LLVMdev] Problems with the exception handling in Objective-C on ARM platform

Mathias Bauer mathias_bauer at gmx.net
Mon Feb 24 06:17:15 PST 2014


Hi,

I'm porting an Objective-C library from MacOS X to Linux/ARM. While the 
port on Linux/X86 runs fine, I have problems on ARM. The biggest 
obstacle I found is exception handling and stack unwinding.

 From prior discussions I learned that exception handling on ARM is best 
supported by the most recent llvm version, so I checked out the trunk 
version and built the following libraries with it:

- libobjc2
- GNUstep base
- my own code
- libdispatch

I used -fobjc-runtime=gnustep-1.7 for the Objective-C code (libdispatch 
is compiled as C code).

Soon I discovered that though some basic exception handling support is 
there, there's still something wrong with it.

The following code example, that uses the "Test" class from the 
ExceptionTest.m in libobjc2, works fine:

> int test()
> {
> 	@throw [Test new];	
> }
>
> int main(void)
> {
> 	@try
> 	{
>	    test();
> 	}
> 	@catch (id x)
> 	{
> 	}
> 	return 0;
> }

And also the following works:

> int main(void)
> {
> 	@try
> 	{
>	    @throw [Test new];
> 	}
> 	@catch (id x)
> 	{
> 	}
>
> 	@try
> 	{
>	    @throw [Test new];
> 	}
> 	@catch (id x)
> 	{
> 	}
> 	return 0;
> }

But this code never terminates:

> int test()
> {
> 	@try
> 	{
> 	    @throw [Test new];
> 	}
> 	@catch (id x)
> 	{
> 	}
> 	
> 	@throw [Test new];	
> }
>
> int main(void)
> {
> 	@try
> 	{
> 	    test();
> 	}
> 	@catch (id x)
> 	{
> 	}
> 	return 0;
> }

The reason is that the the "internal_objc_personality" function in 
eh_personality.c, that tries to find an exception handler, always finds 
a cleanup only, and so always returns _URC_CONTINUE_UNWIND. Thus this 
process never stops.

The same code compiled on X86 also first finds a cleanup, but in the 
second call to internal_objc_personality it finally finds a suitable 
handler and the program continues normally.

My first guess is that this most probably is a compiler problem, as the 
same code and runtime works fine on Linux X86, so my hope is that 
someone on this list has an idea what could be the culprit.

Any help would be greatly appreciated!

Best regards,
Mathias



More information about the llvm-dev mailing list