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

On Tue, Apr 09, 2019 at 02:23:53PM +1000, Michael Ellerman wrote:

I'd much rather we use a trap with a specific immediate value. Otherwise
someone's going to waste time one day puzzling over why userspace is
doing mtmsr.

It's data.  We have other data in executable sections.  Anyone who
wonders about odd disassembly just hasn't realized they are
disassembling data.

It would also complicate things if we ever wanted to emulate mtmsr.

No, because it won't be executed.  If I understand correctly, the only
reason to choose an illegal, trap or privileged insn is to halt
execution earlier rather than later when a program goes off in the
weeds.

If we want something that is a trap rather than a nop then use 0x0fe50553.

That's "compare the value in r5 with 0x553 and then trap unconditionally".

It shows up in objdump as:

    10000000:	53 05 e5 0f 	twui    r5,1363


The immediate can be anything, I chose that value to mimic the x86 value
Mathieu mentioned.

There's no reason that instruction would ever be generated because the
immediate value serves no purpose. So it satisfies the "very unlikely
to appear" criteria AFAICS.

Yes, looks fine to me, except that in VLE mode (do we care?)
".long 0x0fe50553" disassembles as
   0:	0f e5       	se_cmphl r5,r30
   2:	05 53       	se_mullw r3,r5
No illegal/trap/privileged insn there.

".long 0x0fe5000b" might be better to cover VLE.

-- 
Alan Modra
Australia Development Lab, IBM