Re: [PATCH] eliminate mutex in fast path of __register_frame

2022-03-03 Thread Thomas Neumann via Gcc-patches
We may have to add a new interface. In some other cases, I've seen errno being used for error reporting, but that requires changes in applications to recognize the error. It's probably better to crash here than to fail mysteriously later. Out of curiosity, how many times do you call the registr

Re: [PATCH] eliminate mutex in fast path of __register_frame

2022-03-03 Thread Florian Weimer via Gcc-patches
* Thomas Neumann: >>> +// Common logic for version locks >>> +struct version_lock >>> +{ >>> + // The lock itself >>> + uintptr_t version_lock; >>> +}; >> version_lock must not overflow, right? This means we need a wider >> counter on 32-bit, too. glibc contains a 62-bit counter that it uses >

Re: [PATCH] eliminate mutex in fast path of __register_frame

2022-03-02 Thread Thomas Neumann via Gcc-patches
+// Common logic for version locks +struct version_lock +{ + // The lock itself + uintptr_t version_lock; +}; version_lock must not overflow, right? This means we need a wider counter on 32-bit, too. glibc contains a 62-bit counter that it uses for its own data structure. an overflow is

Re: [PATCH] eliminate mutex in fast path of __register_frame

2022-03-02 Thread Florian Weimer via Gcc-patches
* Thomas Neumann: > +#ifndef HIDE_EXPORTS > +#pragma GCC visibility push(default) > +#endif All defined functions are static, right? Then this isn't necessary. > +// Common logic for version locks > +struct version_lock > +{ > + // The lock itself > + uintptr_t version_lock; > +}; version_lo

[PATCH] eliminate mutex in fast path of __register_frame

2022-03-01 Thread Thomas Neumann via Gcc-patches
The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is somewhat expensive even if single-threaded. There was already a