This is an archive of the discontinued LLVM Phabricator instance.

[libunwind] Rename __personality_routine to _Unwind_Personality_Fn
ClosedPublic

Authored by zero9178 on Jan 28 2020, 2:29 PM.

Details

Summary

This patch renames personality_routine to _Unwind_Personality_Fn in unwind.h. Both unwind.h from clang and GCC headers use this name instead of __personality_routine. With this patch one is also able to build libc++abi with libunwind support on Windows.

Would need someone to commit this for me if accepted.

Diff Detail

Event Timeline

zero9178 created this revision.Jan 28 2020, 2:29 PM

Why not rename __personality_routine to _Unwind_Personality_Fn? I don't think that _Unwind_Personality_Fn is part of either the ABI-EH, gABI, or PSABI, but, it is acceptable for GCC compatibility.

zero9178 updated this revision to Diff 241870.Feb 1 2020, 2:58 AM
zero9178 retitled this revision from [libunwind] Add _Unwind_Personality_Fn typedef to unwind.h header to [libcxxabi] Changed use of _Unwind_Personality_Fn to __personality_routine.
zero9178 edited the summary of this revision. (Show Details)

Instead of changing the libunwind header to contain _Unwind_Personality_Fn, changed libcxxabi to use __personality_routine

Instead of changing the libunwind header to contain _Unwind_Personality_Fn, changed libcxxabi to use __personality_routine

Hmm, this isn't quite the way I interpreted @compnerd's comment

Why not rename __personality_routine to _Unwind_Personality_Fn? I don't think that _Unwind_Personality_Fn is part of either the ABI-EH, gABI, or PSABI, but, it is acceptable for GCC compatibility.

I interpret this as suggesting changing the instances of __personality_routine to _Unwind_Personality_Fn, instead of adding a new typedef (as you did in the previous iteration of the patch).

Instead of changing the libunwind header to contain _Unwind_Personality_Fn, changed libcxxabi to use __personality_routine

Hmm, this isn't quite the way I interpreted @compnerd's comment

Why not rename __personality_routine to _Unwind_Personality_Fn? I don't think that _Unwind_Personality_Fn is part of either the ABI-EH, gABI, or PSABI, but, it is acceptable for GCC compatibility.

I interpret this as suggesting changing the instances of __personality_routine to _Unwind_Personality_Fn, instead of adding a new typedef (as you did in the previous iteration of the patch).

... although I see that isn't easily doable, as libuwind is full of use of that type.

As far as I understand __personality_routine is the way the various standards call it, so introducing a GCC specific typedef seems unnecessary and not portable to me

I think that we would want to retain the ability to build libc++abi against libgcc_s. If that also vends a __personality_routine type, then this would definitely be preferable.

I think that we would want to retain the ability to build libc++abi against libgcc_s. If that also vends a __personality_routine type, then this would definitely be preferable.

Grepping in gcc.git gives me no hits for __personality_routine, so standard or not, we should probably keep using the gcc name for the typedef here then, and provide both in libunwind's header.

Just noticed that the unwind.h header of gcc does not provide a __personality_routine typedef. So we have 3 different unwind.h headers.

  • unwind.h from libunwind: Defines __personality_routine but not _Unwind_Personality_Fn
  • unwind.h from clang Headers: Defines both
  • unwind.h from GCC Headers: Defines only _Unwind_Personality_Fn

Not quite sure how to handle this I must say. Maybe adding _Unwind_Personality_Fn to libunwind after all wouldn't be too bad

I don't really mind either way. If you are using clang, you are really not expecting to use <unwind.h> in libunwind without going through the clang header, which has both versions defined.

zero9178 updated this revision to Diff 242081.Feb 3 2020, 8:09 AM
zero9178 retitled this revision from [libcxxabi] Changed use of _Unwind_Personality_Fn to __personality_routine to [libunwind] Add _Unwind_Personality_Fn typedef.
zero9178 edited the summary of this revision. (Show Details)

Reverted back to defining _Unwind_Personality_Fn in unwind.h

I think that we should switch everything to just _Unwind_Personality_Fn and remove __personality_routine.

zero9178 updated this revision to Diff 242927.Feb 6 2020, 9:28 AM
zero9178 retitled this revision from [libunwind] Add _Unwind_Personality_Fn typedef to [libunwind] Rename __personality_routine to _Unwind_Personality_Fn.
zero9178 edited the summary of this revision. (Show Details)

Refactored all uses of __personality_routine to _Unwind_Personality_Fn

I hope we are not renaming everything because it add complexity on compatibility.

Rename only the refs from libunwind is not enough since there are refs from clang header and libc++abi as well. unwind.h and corresponding header from clang are both shipping products which add compatibility problem.

zero9178 added a comment.EditedFeb 6 2020, 1:21 PM

I hope we are not renaming everything because it add complexity on compatibility.

Rename only the refs from libunwind is not enough since there are refs from clang header and libc++abi as well. unwind.h and corresponding header from clang are both shipping products which add compatibility problem.

Git grepping for __ personality_routine after the patch yields only three results. One is the typedef inside of the clang Headers, Two are inside of tests of llvm that I am not sure are relevant here. libc++abi uses the name _Unwind_Personality_Fn instead of __personality_routine that libunwind has used prior to this patch. _Unwind_Personality_Fn is also what GCC calls it. So this patch actually makes it possible to compile libc++abi with libunwind (Build errors only show up on windows since only windows has actually used _Unwind_Personality_Fn ).

Regarding compatibility I am not sure, but I thought users are expected to include unwind.h from clang Headers anyways.

I hope we are not renaming everything because it add complexity on compatibility.

Rename only the refs from libunwind is not enough since there are refs from clang header and libc++abi as well. unwind.h and corresponding header from clang are both shipping products which add compatibility problem.

Git grepping for __ personality_routine after the patch yields only three results. One is the typedef inside of the clang Headers, Two are inside of tests of llvm that I am not sure are relevant here. libc++abi uses the name _Unwind_Personality_Fn instead of __personality_routine that libunwind has used prior to this patch. _Unwind_Personality_Fn is also what GCC calls it. So this patch actually makes it possible to compile libc++abi with libunwind (Build errors only show up on windows since only windows has actually used _Unwind_Personality_Fn ).

Regarding compatibility I am not sure, but I thought users are expected to include unwind.h from clang Headers anyways.

Won't the typedef in clang header turns into an error? That is also the compatibility problem. If you have a mismatch between clang header and libunwind header, it is going to break one way or the other.

I hope we are not renaming everything because it add complexity on compatibility.

Rename only the refs from libunwind is not enough since there are refs from clang header and libc++abi as well. unwind.h and corresponding header from clang are both shipping products which add compatibility problem.

Git grepping for __ personality_routine after the patch yields only three results. One is the typedef inside of the clang Headers, Two are inside of tests of llvm that I am not sure are relevant here. libc++abi uses the name _Unwind_Personality_Fn instead of __personality_routine that libunwind has used prior to this patch. _Unwind_Personality_Fn is also what GCC calls it. So this patch actually makes it possible to compile libc++abi with libunwind (Build errors only show up on windows since only windows has actually used _Unwind_Personality_Fn ).

Regarding compatibility I am not sure, but I thought users are expected to include unwind.h from clang Headers anyways.

Won't the typedef in clang header turns into an error? That is also the compatibility problem. If you have a mismatch between clang header and libunwind header, it is going to break one way or the other.

I don't think that is a real concern - the typedef is local, and references a local definition (that is, clang's unwind.h defines both __Unwind_Personality_Fn and __personality_routine).

Furthermore, @zero9178 didn't mention that the local definition that exists actually is under a preprocessor macro for ARM EHABI specifically. So you are looking at a mismatch on ARM (GNU)EABI environments where it would have previously caused an error already in K&R, ANSI, or C89 due to the type redefinition. In C99 or newer, the type redefinition is permitted and then the type alias will reference the locally declared function type. This is all ignoring the fact that mixing and matching the headers like that is already prone to errors.

I believe that the patch in the current incarnation is the right approach.

steven_wu accepted this revision.Feb 7 2020, 1:06 PM

I see. I don't really care then. LGTM!

This revision is now accepted and ready to land.Feb 7 2020, 1:06 PM

Thank you! Would need someone to commit this for me

compnerd accepted this revision.Feb 10 2020, 8:49 AM