Bringing rseq back into glibc
Florian Weimer
fweimer@redhat.com
Thu Nov 18 19:43:53 GMT 2021
* Mathieu Desnoyers:
> ----- On Nov 18, 2021, at 1:48 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
>
>> On Thu, Nov 18, 2021 at 7:17 AM Florian Weimer via Libc-alpha
>> <libc-alpha@sourceware.org> wrote:
>>
>>> 4. Add public symbols __rseq_abi_offset, __rseq_abi_size (currently 32
>>> or 0), __rseq_abi_flags (currently 0). __rseq_abi_offset is the
>>> offset to add to the thread pointer (see __builtin_thread_pointer) to
>>> get to the rseq area. They will be public ABI symbols. These
>>> variables are initialized before user code runs, and changing the
>>> results in undefined behavior.
>>
>> Why not then __get_rseq_whatwever functions and not variables ? or
>> maybe writing to these variables results in a compiler or linker error
>> instead of UB ?
>
> rseq critical sections cannot issue function calls, and also function calls
> are noticeably expensive compared to an rseq critical section. So all users
> would end up needing to make a local copy of the information fetched by those
> getters.
>
> So rather than require all those extra per-user copies, I suspect exposing
> a single copy through public glibc symbols is more efficient.
Right, and users that want the last bit of performance can still create
local copies.
> The downside is indeed that writing to those variables is UB.
So is writing garbage to the rseq area. 8-) I will see if we can declare
this variables as extern const, and make writes to them terminate the
process.
Thanks,
Florian
More information about the Libc-alpha
mailing list