[PATCH] D15781: [compiler-rt] Add support for ARM EHABI to gcc_personality_v0.

[Logan Chien via llvm-commits]

logan added a comment.

In http://reviews.llvm.org/D15781#317533, @compnerd wrote:

> I didn't mean to imply the C++ personality.  The reconfiguration of the C personality makes things harder IMO.  Now you need to rebuild the library if something changes and control that.  If you absolutely must use this approach, why not introduce a new routine that dispatches as you want (just to be clear this would be different from the language specific personality)?  The entire thing with the personalities is that they handle things one way only and you switch the one that is used.


I feel the discussion is diverged.  That's the reason why I can't get your points.  If I comprehend the thread correctly, two topics are mentioned:

1. The compiler-rt implementation of `__gcc_personality_v0()` is not following ARM EHABI convention.

2. Rather the compiler or run-time for **Rust programming language** should define their own personality function or not.

However, IMO, the second topic is irrelevant to this patch.  Although this issue is reported by the Rust community, it reveals a general problem in compiler-rt for C programming language.  Defining a Rust-specific personality won't fix the C programming language side.

Thus, I would like to focus on the first topic.  My arguments are based on these two questions:

1. When will `clang` or `gcc` generate references to `__gcc_personality_v0()`?
==============================================================================

The answer to this question is simple and easy to verify.  Simply write a program with `__attribute__((cleanup(function)))` and compile the program with `gcc -fexceptions`:

  $ cat > test.c <<__EOF__
  #include <stdio.h>
  
  extern void may_throw();
  
  void my_cleanup(int *p) {
    printf("%d\n", *p);
  }
  
  void test() {
    int a __attribute__((cleanup(my_cleanup))) = 10;
    may_throw();
  }
  __EOF__

Compile the program with `-fexceptions`:

  $ gcc -fexceptions test.c -S

Check the output:

  $ grep __gcc_personality_v0 test.s
  	.cfi_personality 0x3,__gcc_personality_v0
  	.globl	__gcc_personality_v0



2. Is `__gcc_personality_v0()` working on ARM?  If it is not working, how do we fix it?
=======================================================================================

I don't have time to give it a trail these days.  But I would speculate it won't work on ARM platform.  Its function signature and its behavior are not conforming to the ARM EHABI specification, which most unwinders assume.

To get this work, we have to have a slightly different implementation of `__gcc_personality_v0()` for ARM platform.  That's the reason why we need those `#ifdef`s.  I won't call these as reconfiguration, since this is the correct way to define a personality on normal ARM platform.

In detail, to fix `__gcc_personality_v0()` for ARM, we have to:

1. Change the function signature.

2. Unwind the virtual frame before returning _URC_CONTINUE_UNWIND.

And this patch is exactly addressing these issues.


http://reviews.llvm.org/D15781