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

----- On Apr 23, 2019, at 7:59 AM, Ramana Radhakrishnan ramana.gcc@googlemail.com wrote:

On Tue, Apr 23, 2019 at 12:16 PM Szabolcs Nagy [off-list ref] wrote:

quoted

On 18/04/2019 19:17, Mathieu Desnoyers wrote:

quoted

----- On Apr 18, 2019, at 1:37 PM, Szabolcs Nagy Szabolcs.Nagy@arm.com wrote:

quoted

you have to add a documentation comment somewhere
explaining if RSEQ_SIG is the value that's passed to
the kernel and then aarch64 asm code has to use

.inst endianfixup(RSEQ_SIG) // or
.word RSEQ_SIG

Using ".word" won't allow objdump to show the instruction it
maps to. It will consider it as data. So .inst is preferred here.

is there some specific reason you prefer .inst?

I believe the reasoning here is that in the disassembly you want to
see an instruction pattern for an architecture rather than a magic bit
pattern that appears to be an "inline" literal pool entry.  I would
support the .inst variant so that the disassembler shows the
instruction for what it is when debugging. If control reaches the
marker instruction, something's gone wrong and thus from a user
friendliness perspective I would prefer to see an instruction that
clearly indicates that it's undefined .inst directive so that someone
disassembling this in an assembly view in GDB sees the right thing
(TM) instead of having to reach for the manual and disassembling this
by hand.

That's my line of thinking exactly. I might add that having data in a
literal pool within the instruction stream might be unexpected in some
compilation environments, e.g. when compiling with -mno-text-section-literals .

So even though the signature may likely end up being placed in a literal
pool, it's preferable to ensure it is a valid uncommon trap instruction.

Thanks,

Mathieu

quoted

disassembling a canary value as data (that is
never executed, but loaded and compared by the
kernel as data) sounds more semantically correct
to me than showing it as an instruction.

Ramana

quoted

i guess having it as an instruction can avoid
issues if some tools dislike .word in .text,
but otherwise .word seems better.

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com