Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)

From: Carlos O'Donell
Date: Thu Apr 04 2019 - 16:16:01 EST


On 4/2/19 2:02 AM, Michael Ellerman wrote:
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> writes:
Hi Carlos,

----- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codonell@xxxxxxxxxx wrote:
...

[...]
+++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h
[...]
+/* Signature required before each abort handler code. */
+#define RSEQ_SIG 0x53053053

Why isn't this an opcode specific to power?

On powerpc 32/64, the abort is placed in a __rseq_failure executable section:

#define RSEQ_ASM_DEFINE_ABORT(label, abort_label) \
".pushsection __rseq_failure, \"ax\"\n\t" \
".long " __rseq_str(RSEQ_SIG) "\n\t" \
__rseq_str(label) ":\n\t" \
"b %l[" __rseq_str(abort_label) "]\n\t" \
".popsection\n\t"

That section only contains snippets of those trampolines. Arguably, it would be
good if disassemblers could find valid instructions there. Boqun Feng could perhaps
shed some light on this signature choice ? Now would be a good time to decide
once and for all whether a valid instruction would be a better choice.

I'm a bit vague on what we're trying to do here.

But it seems like you want some sort of "eye catcher" prior to the branch?

That value is a valid instruction on current CPUs (rlwimi.
r5,r24,6,1,9), and even if it wasn't it could become one in future.

If you change it to 0x8053530 that is both a valid instruction and is a
nop (conditional trap immediate but with no conditions set).

The s390 IBM team needs to respond to this and I want to make sure they ACK
the NOP being used here because it impacts them directly.

I'd like to see Martin's opinion on this.

--
Cheers,
Carlos.