On Wed, 24 Apr 2019, Paul Burton wrote:
> > > 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
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
- On Apr 18, 2019, at 2:58 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 4, 2019, at 5:41 PM, Paul Burton paul.bur...@mips.com wrote:
> [...]
>
>>> 2a. A uncommon TRAP hopefully with some immediate data encoded (maybe
>>> uncommon)
>>
>> Our break instruction
- On Apr 4, 2019, at 5:41 PM, Paul Burton paul.bur...@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:
>
- On Apr 9, 2019, at 5:29 AM, Alan Modra amo...@gmail.com wrote:
> 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
- On Apr 4, 2019, at 5:41 PM, Paul Burton paul.bur...@mips.com wrote:
> Hi Carlos / all,
>
> On Thu, Apr 04, 2019 at 04:50:08PM -0400, Carlos O'Donell wrote:
>> > > > +/* Signature required before each abort handler code. */
>> > > > +#define RSEQ_SIG 0x53053053
>> > >
>> > > Why isn't
- On Apr 8, 2019, at 5:45 PM, Carlos O'Donell codon...@redhat.com wrote:
> On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote:
>> Carlos O'Donell writes:
>>
>>> On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
> It is valuable that it be a trap, particularly for
- On Apr 9, 2019, at 10:13 AM, Carlos O'Donell codon...@redhat.com wrote:
> On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote:
>> Alan Modra writes:
>>> Yes, looks fine to me, except that in VLE mode (do we care?)
>>> ".long 0x0fe50553" disassembles as
>>> 0: 0f e5
On 4/9/19 9:58 AM, Tulio Magno Quites Machado Filho wrote:
Alan Modra writes:
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.
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
Carlos O'Donell writes:
> On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote:
>> Carlos O'Donell writes:
>>
>>> On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
> It is valuable that it be a trap, particularly for constant pools because
> it means that a jump into
On 4/8/19 3:20 PM, Tulio Magno Quites Machado Filho wrote:
Carlos O'Donell writes:
On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
It is valuable that it be a trap, particularly for constant pools because
it means that a jump into the constant pool will trap.
Sorry, I don't
Carlos O'Donell writes:
> On 4/5/19 5:16 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>> It is valuable that it be a trap, particularly for constant pools because
>>> it means that a jump into the constant pool will trap.
>>
>> Sorry, I don't understand why this matters in this context.
On 4/5/19 5:16 AM, Florian Weimer wrote:
* Carlos O'Donell:
It is valuable that it be a trap, particularly for constant pools because
it means that a jump into the constant pool will trap.
Sorry, I don't understand why this matters in this context. Would you
please elaborate?
Sorry, I
* Carlos O'Donell:
> On 4/2/19 3:08 AM, Florian Weimer wrote:
>> * Michael Ellerman:
>>
>>> I'm a bit vague on what we're trying to do here.
>>>
>>> But it seems like you want some sort of "eye catcher" prior to the branch?
>>>
>>> That value is a valid instruction on current CPUs (rlwimi.
>>>
Hi Carlos / all,
On Thu, Apr 04, 2019 at 04:50:08PM -0400, Carlos O'Donell wrote:
> > > > +/* Signature required before each abort handler code. */
> > > > +#define RSEQ_SIG 0x53053053
> > >
> > > Why isn't this a mips-specific op code?
> >
> > MIPS also has a literal pool just before the
On 3/25/19 11:54 AM, Mathieu Desnoyers wrote:
Hi Carlos,
- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
[...]
I took care of all your comments for an upcoming round of patches, except the
following that remain open (see answer inline). I'm adding Linux
On 4/2/19 3:08 AM, Florian Weimer wrote:
* Michael Ellerman:
I'm a bit vague on what we're trying to do here.
But it seems like you want some sort of "eye catcher" prior to the branch?
That value is a valid instruction on current CPUs (rlwimi.
r5,r24,6,1,9), and even if it wasn't it could
On 4/2/19 2:02 AM, Michael Ellerman wrote:
Mathieu Desnoyers writes:
Hi Carlos,
- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
...
[...]
+++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h
[...]
+/* Signature required before each abort handler code. */
* Michael Ellerman:
> I'm a bit vague on what we're trying to do here.
>
> But it seems like you want some sort of "eye catcher" prior to the branch?
>
> That value is a valid instruction on current CPUs (rlwimi.
> r5,r24,6,1,9), and even if it wasn't it could become one in future.
>
> If you
Mathieu Desnoyers writes:
> Hi Carlos,
>
> - On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
...
>
> [...]
>>> +++ b/sysdeps/unix/sysv/linux/powerpc/bits/rseq.h
> [...]
>>> +/* Signature required before each abort handler code. */
>>> +#define RSEQ_SIG 0x53053053
>>
- On Mar 28, 2019, at 3:49 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Wed, 27 Mar 2019 16:38:32 -0400
> "Carlos O'Donell" wrote:
>
>> On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
>> > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
>> > Mathieu Desnoyers wrote:
>> >
>> +++
On Wed, 27 Mar 2019 16:38:32 -0400
"Carlos O'Donell" wrote:
> On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
> > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
> > Mathieu Desnoyers wrote:
> >
> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
> >> [...]
> +
> +/* Signature
On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
Mathieu Desnoyers wrote:
+++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
[...]
+
+/* Signature required before each abort handler code. */
+#define RSEQ_SIG 0x53053053
Why not a s390 specific value
- On Mar 27, 2019, at 5:16 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> >> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
>> [...]
>> >> +
>> >> +/* Signature required before each abort handler code. */
>> >>
On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
Mathieu Desnoyers wrote:
> >> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h
> [...]
> >> +
> >> +/* Signature required before each abort handler code. */
> >> +#define RSEQ_SIG 0x53053053
> >
> > Why not a s390 specific value here?
>
> s390 also
Hi Carlos,
- On Mar 22, 2019, at 4:09 PM, Carlos O'Donell codon...@redhat.com wrote:
[...]
I took care of all your comments for an upcoming round of patches, except the
following that remain open (see answer inline). I'm adding Linux maintainers
for ARM, aarch64, MIPS, powerpc, s390, x86 in
On 2/12/19 2:42 PM, Mathieu Desnoyers wrote:
Register rseq(2) TLS for each thread (including main), and unregister
for each thread (excluding main). "rseq" stands for Restartable
Sequences.
Thanks, the implementation is looking good, before this goes in it needs
some procedural cleanup and the
Register rseq(2) TLS for each thread (including main), and unregister
for each thread (excluding main). "rseq" stands for Restartable
Sequences.
See the rseq(2) man page proposed here:
https://lkml.org/lkml/2018/9/19/647
This patch is based on glibc-2.29. The rseq(2) system call was merged
- On Feb 4, 2019, at 4:28 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Register rseq(2) TLS for each thread (including main), and unregister
> for each thread (excluding main). "rseq" stands for Restartable
> Sequences.
>
> See the rseq(2) man page proposed here:
>
Register rseq(2) TLS for each thread (including main), and unregister
for each thread (excluding main). "rseq" stands for Restartable
Sequences.
See the rseq(2) man page proposed here:
https://lkml.org/lkml/2018/9/19/647
This patch is based on glibc-2.29. The rseq(2) system call was merged
31 matches
Mail list logo
