Messages in this thread | | | Subject | Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) | From | Carlos O'Donell <> | Date | Wed, 27 Mar 2019 16:38:32 -0400 |
| |
On 3/27/19 5:16 AM, Martin Schwidefsky wrote: > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT) > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > >>>> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h >> [...] >>>> + >>>> +/* Signature required before each abort handler code. */ >>>> +#define RSEQ_SIG 0x53053053 >>> >>> Why not a s390 specific value here? >> >> s390 also has the abort handler in a __rseq_failure section: >> >> #define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \ >> ".pushsection __rseq_failure, \"ax\"\n\t" \ >> ".long " __rseq_str(RSEQ_SIG) "\n\t" \ >> __rseq_str(label) ":\n\t" \ >> teardown \ >> "j %l[" __rseq_str(abort_label) "]\n\t" \ >> ".popsection\n\t" >> >> Same question applies as powerpc: since disassemblers will try to decode >> that instruction, would it be better to define it as a valid one ? >> >> [...] > > A 4-byte sequence starting with 0x53 is decoded as a "diebr" instruction. > And please replace that "j %l[...]" with a "jg %l[...]", the branch target > range of the "j" instruction is 64K, not enough for the general case.
Why was this particular operated selected?
So on s390 the RSEQ_SIG will show up as an unexpected "divide to integer" instruction that can't be reached by any control flow?
Can we use a NOP with a unique value in an immediate operand?
The goal being to have something that won't confuse during a debug session, or that the debugger can ignore (like constant pools on Arm)
-- Cheers, Carlos.
| |