This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

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 stack space.  Its
> only purpose is to provide a SEGV if there is not enough kernel stack.
> Look for`-fstack-check' as a GCC argument.
> Andrew.

Okay, that explains that.  I rebuilt the affected kernel with
'-fno-stack-check', and that particular platform boots now (it has other
issues, but it at least gets past early init).

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, at the point that _raw_spin_lock_irq is called and the
stack-probe happens, that there isn't any stack space available because the
IP27-specific memory init hasn't yet completed?

Joshua Kinard
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]