On 01/23/2017 11:24, Andrew Haley wrote:
> On 23/01/17 16:11, Joshua Kinard wrote:
>> So now the question is why stack-probing kills this machine on generic MIPS
>> code that its smaller cousin is seemingly unaffected by. I do know that IP27
>> has a different set of memory initialization routines
On 23/01/17 16:11, Joshua Kinard wrote:
> So now the question is why stack-probing kills this machine on generic MIPS
> code that its smaller cousin is seemingly unaffected by. I do know that IP27
> has a different set of memory initialization routines in the MIPS code, so is
> it possible that, a
On 01/23/2017 10:34, Andrew Haley wrote:
> On 23/01/17 15:26, Joshua Kinard wrote:
>> I am not sure what this lone store-doubleword instruction is exactly doing,
>> nor
>> can I locate where in the gcc MIPS code it is being generated from.
>
> It's a stack probe, making sure that there is enough
On 23/01/17 15:26, Joshua Kinard wrote:
> I am not sure what this lone store-doubleword instruction is exactly doing,
> nor
> can I locate where in the gcc MIPS code it is being generated from.
It's a stack probe, making sure that there is enough stack space. Its
only purpose is to provide a SE
Hi,
I am trying to use gcc-6.3.0 to cross-compile a kernel for an old mips64
platform, an SGI Onyx2 ("IP27"), however, it looks like a large number of
functions within the compiled code are getting a common instruction emitted at
the top of the function that breaks this particular machine.
Doing
