This makes the formerly hard dependency on libpthread into a weak
dependency.
Details
- Reviewers
ldionne grosbach kledzik - Commits
- rZORG2169ef21e45d: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread…
rZORG67bf9a954a1d: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread…
rG2169ef21e45d: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread…
rG67bf9a954a1d: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread…
rUNW360610: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force
rG7981a28d9d30: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force calls into the pthread…
rL360610: Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 31707 Build 31706: arc lint + arc unit
Event Timeline
What problem are you trying to solve with this?
I think we talked about it already in a different setting, but why not implement a no-op RWMutex instead?
This is better than a no-op RWMutex because then the same binary works both when the application is multi-threaded and when it isn't. Therefore the build doesn't have to distinguish between the two cases.
libunwind/src/RWMutex.hpp | ||
---|---|---|
62 | When you redeclare functions like this, are attributes stacked with the attributes of other (previous) declarations? | |
73 | Just to make sure I understand: pthread_create != nullptr is only going to be satisfied if pthread_create was linked into the program, _and_ it was used at least once before? I thought it would be non-null whenever it was linked into the program, whether you used it or not. |
libunwind/src/RWMutex.hpp | ||
---|---|---|
62 | The gcc documentation says so. 6.33 Declaring Attributes of Functions The clang docs aren't specific on this point. But I know of enough uses of this style that I would consider it a bug if it didn't. | |
73 | It will be non-null only if it was linked. Whether or not it was used makes no difference. This is more conservative than strictly necessary, but it saves the complexity of tracking whether or not multiple threads are actually active. |
Nick any thoughts? I'd like to move forward, for whatever definition of "forward" we may settle on.
Hi Nick--hope your vacation was good.
When you get a chance, would you respond to ldionne's question above?
Can this be conditionalized to not happen on macOS/iOS? I can see needing this on platforms where pthreads is optional, but it looks like this code will apply to macOS too, which introduces risk there.
Given this, I think implementing a no-op RWMutex is a better solution. And if you need the ability for the same library to work in both cases, maybe this code could be in a WeakRWMutex (or something like that).
I've now put the weak-reference version behind a non-default build option. Is this acceptable?
libunwind/src/CMakeLists.txt | ||
---|---|---|
70 | This is not an existing CMake option, is it? You should add it. |
This is not an existing CMake option, is it? You should add it.