search for: gxx_personality_v0

...9;m compiling this trivial program on Darwin: int main(int argc, char **argv) { try { throw argc; } catch(int i) { return i; } return 0; } However, it segfaults when I run it. I've attached the .s files generated by LLVM and GCC, but it looks as if LLVM isn't generating a gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is this what's causing the failure? Does anyone know how to get it to generate this section? Thanks! -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: t.gcc.s Type: application/octet-stream Size: 4259 bytes...

...argc, char **argv) { > try { > throw argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a > gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is > this what's causing the failure? Does anyone know how to get it to > generate this section? does it segfault if you link using mainline g++? Where does the segfault occur - in the unwinder, or in the program itself (and if so, where)...

...t argc, char **argv) { > try { > throw argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a > gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is > this what's causing the failure? Does anyone know how to get it to > generate this section? The most obvious thing different is that gcc expects the return value of the throw (EDX) to be 1, while llvm expects it to be 2. Try changi...

...n libc++abi. In particular, as you mention, __cxa_type_match needs the rtti info. That said, currently this part is not implemented in libunwind, among others because clang never generates code that uses arm-defined PRs for exceptions and cleanup, only for trivial frame unwinding (it always uses __gxx_personality_v0 for exceptions/cleanup), so I don't think today libunwind depends on libc++abi, except for the recent patch for _Unwind_Backtrace. Antoine > > On 10/22/14 11:39 AM, Renato Golin wrote: > > So, I remember we discussed this earlier this year, but I can't find the > thread. &...

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the