----- On Apr 23, 2019, at 7:59 AM, Ramana Radhakrishnan ramana.gcc@xxxxxxxxxxxxxx wrote: > On Tue, Apr 23, 2019 at 12:16 PM Szabolcs Nagy <Szabolcs.Nagy@xxxxxxx> wrote: >> >> On 18/04/2019 19:17, Mathieu Desnoyers wrote: >> > ----- On Apr 18, 2019, at 1:37 PM, Szabolcs Nagy Szabolcs.Nagy@xxxxxxx wrote: >> >> 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 > >> >> 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 > > >> 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
