From: Paul Burton <paul.burton@mips.com> To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Carlos O'Donell <codonell@redhat.com>, Will Deacon <will.deacon@arm.com>, Boqun Feng <boqun.feng@gmail.com>, heiko carstens <heiko.carstens@de.ibm.com>, gor <gor@linux.ibm.com>, schwidefsky <schwidefsky@de.ibm.com>, "Russell King, ARM Linux" <linux@armlinux.org.uk>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, carlos <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha <libc-alpha@sourceware.org>, Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>, Peter Zijlstra <peterz@infradead.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>, Rich Felker <dalias@libc.org>, linux-kernel <linux-kernel@vger.kernel.org>, linux-api <linux-api@vger.kernel.org> Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Date: Wed, 24 Apr 2019 23:13:08 +0000 [thread overview] Message-ID: <20190424231303.zu2irxd5g3v7yqey@pburton-laptop> (raw) In-Reply-To: <1103046939.521.1556118342613.JavaMail.zimbra@efficios.com> Hi Mathieu, Just following up on a couple of things here. On Wed, Apr 24, 2019 at 11:05:42AM -0400, Mathieu Desnoyers wrote: > >>> 2a. A uncommon TRAP hopefully with some immediate data encoded (maybe uncommon) > >> > >> Our break instruction has a 19b immediate in nanoMIPS (20b for microMIPS > >> & classic MIPS) so that could be something like: > >> > >> break 0x7273 # ASCII 'rs' > >> > > > > I like this uncommon break instruction as signature choice. > > > > However, if I try to compile assembler with a break 0x7273 instruction > > with mips64 and mips32 toolchains (gcc version 8.2.0 (Ubuntu > > 8.2.0-1ubuntu2~18.04)) > > I get: > > > > /tmp/ccVh9F7T.s: Assembler messages: > > /tmp/ccVh9F7T.s:24: Error: operand 1 out of range `break 0x7273' > > > > It works up to the value 0x3FF, which seems to use the top 10 > > code bits: > > > > a: 03ff 0007 break 0x3ff > > > > Would a "break 0x350" be a good choice as well ? The "break 0x350" instruction seems good to me - it's still going to be rare. > > Any idea why 0x7273 is not accepted by my assembler ? I don't know why the assembler wants a smaller immediate than the instruction encoding allows... There's a comment in the binutils file include/opcode/mips.h that reads: > A breakpoint instruction uses OP, CODE and SPEC (10 bits of the > breakpoint instruction are not defined; Kane says the breakpoint code > field in BREAK is 20 bits; yet MIPS assemblers and debuggers only use > ten bits). An optional two-operand form of break/sdbbp allows the > lower ten bits to be set too, and MIPS32 and later architectures allow > 20 bits to be set with a signal operand (using CODE20). I suspect there's some history here that predates my involvement (or possibly just predates me). > > I also tried crafting the assembler with values between 0x3FF and 0x7273 > > in the 20 code bits. It seems fine from an objdump perspective: > > > > ".long 0x03FFFC7\n\t" > > > > generates: > > > > 10: 003f ffc7 break 0x3f,0x3ff > > > > What I don't understand is why the instruction generated by my > > toolchain ends with the last 6 bits "000111", whereas the mips32 > > instruction set specifies break as ending with "001101" [1]. > > What am I missing ? Were you targeting microMIPS by any chance? There the break32 instructions ends with 000111. > > Also, the nanomips break code [2] has a completely different > > instruction layout. Should we use a different signature when > > compiling for nanomips ? What #ifdef should we use ? Yes, and __nanomips__. I included the encoding in my reply to your RFC patch. > > Do I need a special toolchain to generate nanomips binaries ? Yes, you can find it here: https://codescape.mips.com/components/toolchain/nanomips/latest/index.html We don't have the nanoMIPS kernel support in mainline yet, I've gotten various things applied in preparation but also been swamped with other things so it's taking a while. If you want to see a working downstream kernel though you can find it here: git://git.linux-mips.org/pub/scm/linux-mti.git nanomips-v4.15 > Hi Paul, I'm still waiting for feedback on the MIPS front. > > Meanwhile, I plan to use #define RSEQ_SIG 0x0350000d which maps to: > > 0350000d break 0x350 > > and use RSEQ_SIG in assembly with: > > ".word " __rseq_str(RSEQ_SIG) "\n\t" > > on big and little endian MIPS, for MIPS32 and MIPS64, based on > code generated with gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04). > > Let me know if it needs to be tweaked. That's fine for the classic MIPS ISA, but won't decode as a break for microMIPS or nanoMIPS. See my reply to your RFC for valid encodings for both of those. Thanks, Paul
WARNING: multiple messages have this Message-ID (diff)
From: Paul Burton <paul.burton@mips.com> To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Carlos O'Donell <codonell@redhat.com>, Will Deacon <will.deacon@arm.com>, Boqun Feng <boqun.feng@gmail.com>, heiko carstens <heiko.carstens@de.ibm.com>, gor <gor@linux.ibm.com>, schwidefsky <schwidefsky@de.ibm.com>, "Russell King, ARM Linux" <linux@armlinux.org.uk>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, carlos <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>, Joseph Myers <joseph@codesourcery.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha <libc-alpha@sourceware.org>, Thomas Gleixner <tglx@linutronix.de>, Ben Maurer <bmaurer@fb.com>, Peter Zijlstra <peterz@infradead.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Dave Watson <davejwatson@fb.c> Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Date: Wed, 24 Apr 2019 23:13:08 +0000 [thread overview] Message-ID: <20190424231303.zu2irxd5g3v7yqey@pburton-laptop> (raw) In-Reply-To: <1103046939.521.1556118342613.JavaMail.zimbra@efficios.com> Hi Mathieu, Just following up on a couple of things here. On Wed, Apr 24, 2019 at 11:05:42AM -0400, Mathieu Desnoyers wrote: > >>> 2a. A uncommon TRAP hopefully with some immediate data encoded (maybe uncommon) > >> > >> Our break instruction has a 19b immediate in nanoMIPS (20b for microMIPS > >> & classic MIPS) so that could be something like: > >> > >> break 0x7273 # ASCII 'rs' > >> > > > > I like this uncommon break instruction as signature choice. > > > > However, if I try to compile assembler with a break 0x7273 instruction > > with mips64 and mips32 toolchains (gcc version 8.2.0 (Ubuntu > > 8.2.0-1ubuntu2~18.04)) > > I get: > > > > /tmp/ccVh9F7T.s: Assembler messages: > > /tmp/ccVh9F7T.s:24: Error: operand 1 out of range `break 0x7273' > > > > It works up to the value 0x3FF, which seems to use the top 10 > > code bits: > > > > a: 03ff 0007 break 0x3ff > > > > Would a "break 0x350" be a good choice as well ? The "break 0x350" instruction seems good to me - it's still going to be rare. > > Any idea why 0x7273 is not accepted by my assembler ? I don't know why the assembler wants a smaller immediate than the instruction encoding allows... There's a comment in the binutils file include/opcode/mips.h that reads: > A breakpoint instruction uses OP, CODE and SPEC (10 bits of the > breakpoint instruction are not defined; Kane says the breakpoint code > field in BREAK is 20 bits; yet MIPS assemblers and debuggers only use > ten bits). An optional two-operand form of break/sdbbp allows the > lower ten bits to be set too, and MIPS32 and later architectures allow > 20 bits to be set with a signal operand (using CODE20). I suspect there's some history here that predates my involvement (or possibly just predates me). > > I also tried crafting the assembler with values between 0x3FF and 0x7273 > > in the 20 code bits. It seems fine from an objdump perspective: > > > > ".long 0x03FFFC7\n\t" > > > > generates: > > > > 10: 003f ffc7 break 0x3f,0x3ff > > > > What I don't understand is why the instruction generated by my > > toolchain ends with the last 6 bits "000111", whereas the mips32 > > instruction set specifies break as ending with "001101" [1]. > > What am I missing ? Were you targeting microMIPS by any chance? There the break32 instructions ends with 000111. > > Also, the nanomips break code [2] has a completely different > > instruction layout. Should we use a different signature when > > compiling for nanomips ? What #ifdef should we use ? Yes, and __nanomips__. I included the encoding in my reply to your RFC patch. > > Do I need a special toolchain to generate nanomips binaries ? Yes, you can find it here: https://codescape.mips.com/components/toolchain/nanomips/latest/index.html We don't have the nanoMIPS kernel support in mainline yet, I've gotten various things applied in preparation but also been swamped with other things so it's taking a while. If you want to see a working downstream kernel though you can find it here: git://git.linux-mips.org/pub/scm/linux-mti.git nanomips-v4.15 > Hi Paul, I'm still waiting for feedback on the MIPS front. > > Meanwhile, I plan to use #define RSEQ_SIG 0x0350000d which maps to: > > 0350000d break 0x350 > > and use RSEQ_SIG in assembly with: > > ".word " __rseq_str(RSEQ_SIG) "\n\t" > > on big and little endian MIPS, for MIPS32 and MIPS64, based on > code generated with gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04). > > Let me know if it needs to be tweaked. That's fine for the classic MIPS ISA, but won't decode as a break for microMIPS or nanoMIPS. See my reply to your RFC for valid encodings for both of those. Thanks, Paul
next prev parent reply other threads:[~2019-04-24 23:13 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20190212194253.1951-1-mathieu.desnoyers@efficios.com> 2019-02-12 19:42 ` [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) Mathieu Desnoyers 2019-03-22 20:09 ` Carlos O'Donell 2019-03-25 15:54 ` Mathieu Desnoyers 2019-03-27 9:16 ` Martin Schwidefsky 2019-03-27 9:16 ` Martin Schwidefsky 2019-03-27 20:01 ` Mathieu Desnoyers 2019-03-27 20:01 ` Mathieu Desnoyers 2019-03-27 20:38 ` Carlos O'Donell 2019-03-27 20:38 ` Carlos O'Donell 2019-03-28 7:49 ` Martin Schwidefsky 2019-03-28 7:49 ` Martin Schwidefsky 2019-03-28 15:42 ` Mathieu Desnoyers 2019-03-28 15:42 ` Mathieu Desnoyers 2019-04-02 6:02 ` Michael Ellerman 2019-04-02 7:08 ` Florian Weimer 2019-04-02 7:08 ` Florian Weimer 2019-04-04 20:32 ` Carlos O'Donell 2019-04-04 20:32 ` Carlos O'Donell 2019-04-05 9:16 ` Florian Weimer 2019-04-05 9:16 ` Florian Weimer 2019-04-05 15:40 ` Carlos O'Donell 2019-04-05 15:40 ` Carlos O'Donell 2019-04-08 19:20 ` Tulio Magno Quites Machado Filho 2019-04-08 19:20 ` Tulio Magno Quites Machado Filho 2019-04-08 21:45 ` Carlos O'Donell 2019-04-08 21:45 ` Carlos O'Donell 2019-04-09 4:23 ` Michael Ellerman 2019-04-09 4:23 ` Michael Ellerman 2019-04-09 9:29 ` Alan Modra 2019-04-09 9:29 ` Alan Modra 2019-04-09 13:58 ` Tulio Magno Quites Machado Filho 2019-04-09 14:13 ` Carlos O'Donell 2019-04-09 14:13 ` Carlos O'Donell 2019-04-09 15:45 ` Mathieu Desnoyers 2019-04-09 15:45 ` Mathieu Desnoyers 2019-04-18 15:31 ` Mathieu Desnoyers 2019-04-18 15:31 ` Mathieu Desnoyers 2019-04-09 16:33 ` Mathieu Desnoyers 2019-04-09 16:33 ` Mathieu Desnoyers 2019-04-04 20:15 ` Carlos O'Donell 2019-04-04 20:50 ` Carlos O'Donell 2019-04-04 21:41 ` Paul Burton 2019-04-04 21:41 ` Paul Burton 2019-04-09 16:40 ` Mathieu Desnoyers 2019-04-09 16:40 ` Mathieu Desnoyers 2019-04-18 18:58 ` Mathieu Desnoyers 2019-04-18 18:58 ` Mathieu Desnoyers 2019-04-24 15:05 ` Mathieu Desnoyers 2019-04-24 15:05 ` Mathieu Desnoyers 2019-04-24 23:13 ` Paul Burton [this message] 2019-04-24 23:13 ` Paul Burton 2019-04-25 0:41 ` Maciej W. Rozycki 2019-04-25 0:41 ` Maciej W. Rozycki 2019-02-12 19:42 ` [PATCH 2/4] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux Mathieu Desnoyers 2019-03-22 20:13 ` Carlos O'Donell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190424231303.zu2irxd5g3v7yqey@pburton-laptop \ --to=paul.burton@mips.com \ --cc=benh@kernel.crashing.org \ --cc=bmaurer@fb.com \ --cc=boqun.feng@gmail.com \ --cc=carlos@redhat.com \ --cc=codonell@redhat.com \ --cc=dalias@libc.org \ --cc=davejwatson@fb.com \ --cc=fweimer@redhat.com \ --cc=gor@linux.ibm.com \ --cc=heiko.carstens@de.ibm.com \ --cc=joseph@codesourcery.com \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=mathieu.desnoyers@efficios.com \ --cc=mpe@ellerman.id.au \ --cc=paulmck@linux.vnet.ibm.com \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=schwidefsky@de.ibm.com \ --cc=szabolcs.nagy@arm.com \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.