Add these declarations which should be present in <unwind.h>,
but aren't. Not that it matters, since most of the time we'll be using
Clang's <unwind.h> anyway.
Details
Diff Detail
- Repository
- rUNW libunwind
- Build Status
Buildable 21242 Build 21242: arc lint + arc unit
Event Timeline
NetBSD uses typedef void *_Unwind_Ptr; unconditionally in its <unwind.h>... if that has to be matched.
Additionally: typedef long _Unwind_Word;.
include/unwind.h | ||
---|---|---|
50 | What other reference is this list of typedefs for _Unwind_Ptr based on? I don't see any of these cases in clang's unwind.h at least. | |
185 | Minor nitpick: Would it make sense to move the typedef _Unwind_Personality_Fn __personality_routine; out of the ifdef, since the same one can be used for both cases? |
include/unwind.h | ||
---|---|---|
50 | Where did I get those from...? These seem to be for ARM EHABI, but I can't find them anymore in the GCC source. They aren't in Clang's header, either. I wrote this a while ago... did something change in the meantime? I could probably get away with removing those special cases if we don't really need them. |
- Add NetBSD-specific definitions.
- Pull out common declaration of __personality_routine.
@cdavis5x I presume the fact that this one turned out tricky is blocking submitting the SEH unwinding patch.
Would it be worth to rework that patch to just use the basic types just like libunwind does today, e.g. having _Unwind_GetRegionStart return plain uintptr_t instead of _Unwind_Ptr, which also would be consistent with the existing entry points in Unwind-EHABI.cpp, Unwind-sjlj.c and UnwindLevel1.c, in order to be able to submit it before this one gets sorted out?
Is there a reason for defining them? As in: does anything outside libunwind use them? I haven't seen such software yet.
This doesn't seem like a great idea to me, it's a negligible amount of type safety gained over using stdint.h types most people are more familiar with anyway. If you need something niche like those typedefs it's probably better to include the header and define them yourself in your application.
From my point of view, the number of people who have idea about these types and why do they differ between ABIs and OSes is so low, that it's even hard to get someone to review it here.
Probably not (to disambiguate, as in, it wouldn't hurt).
I'm personally against adding more and more typedefs for things that are just stdint/inttypes.h stuff and I say here the change is insignificant enough to warrant having to define even more types. It's not causing any problems but unless there are actual custom composite types that belong in that header, I don't see the benefit of them, if everyone starts wanting to typedef trivial types in unwind.h, it could be a maintainability issue. Not talking about this patch specifically but about a precedent of whether trivial types should get more and more aliases, polluting the header, and whether sticking to standard types and aliasing them in implementation is perhaps a better approach. Since the header gets installed everywhere and there isn't something like unifdef removing otherwise dead code. SEH patch was of much bigger significance so in that case it was fine (though I still like insisting on avoiding custom typedefs like DWORD for uint32_t just because rest of LLVM follows the same practice, while new composite types can be a necessity, more and more trivial type aliases isn't).
That's my stance on it. Patch itself is sound however, ignoring what I said above.
So, basically, if we have no internal users for these typedefs, there's no reason to clutter up headers that get installed into system header directories everywhere with dead ifdefed out code. Sounds good to me, let's not do it.
What other reference is this list of typedefs for _Unwind_Ptr based on? I don't see any of these cases in clang's unwind.h at least.