All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Paul Burton <paul.burton@mips.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: Thu, 18 Apr 2019 14:58:20 -0400 (EDT)	[thread overview]
Message-ID: <1031613720.1496.1555613900993.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190404214151.6ogrm34dok52az4h@pburton-laptop>

----- On Apr 4, 2019, at 5:41 PM, Paul Burton paul.burton@mips.com 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'
> 

Hi Paul,

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 ? 

Any idea why 0x7273 is not accepted by my assembler ?

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 ?

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 ? Do I
need a special toolchain to generate nanomips binaries ?

Thanks,

Mathieu

[1] http://hades.mech.northwestern.edu/images/1/16/MIPS32_Architecture_Volume_II-A_Instruction_Set.pdf
[2] https://s3-eu-west-1.amazonaws.com/downloads-mips/I7200/I7200+product+launch/MIPS_nanomips32_ISA_TRM_01_01_MD01247.pdf

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

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Paul Burton <paul.burton@mips.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: Thu, 18 Apr 2019 14:58:20 -0400 (EDT)	[thread overview]
Message-ID: <1031613720.1496.1555613900993.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190404214151.6ogrm34dok52az4h@pburton-laptop>

----- On Apr 4, 2019, at 5:41 PM, Paul Burton paul.burton@mips.com 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'
> 

Hi Paul,

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 ? 

Any idea why 0x7273 is not accepted by my assembler ?

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 ?

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 ? Do I
need a special toolchain to generate nanomips binaries ?

Thanks,

Mathieu

[1] http://hades.mech.northwestern.edu/images/1/16/MIPS32_Architecture_Volume_II-A_Instruction_Set.pdf
[2] https://s3-eu-west-1.amazonaws.com/downloads-mips/I7200/I7200+product+launch/MIPS_nanomips32_ISA_TRM_01_01_MD01247.pdf

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

  parent reply	other threads:[~2019-04-18 18:58 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 [this message]
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
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=1031613720.1496.1555613900993.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.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=mpe@ellerman.id.au \
    --cc=paul.burton@mips.com \
    --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: link
Be 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.