Is this related to the general panic discussed in freebsd-current?

[Andrew Turner]

On Sun, 5 May 2013 09:37:48 -0700
Tim Kientzle <tim at kientzle.com> wrote:
> On May 5, 2013, at 6:00 AM, Andrew Turner wrote:
> 
> > On Sat, 4 May 2013 15:44:37 -0700
> > Tim Kientzle <tim at kientzle.com> wrote:
> >> I'm baffled.  If I insert a printf into the loop in stack_capture,
> >> the kernel boots. But the generated assembly looks perfectly
> >> correct to me in either case.  So inserting the printf must have
> >> some side-effect.
> >> 
> >> The stack does end up aligned differently:  The failing version
> >> puts 16 bytes on the stack, the working version puts 24 bytes.
> >> But I can't figure out how that would explain what I'm seeing...
> > 
> > It feels like an alignment issue but those stack sizes should both
> > be valid. Are you able to send me the asm for the working and broken
> > versions of the function?
> > 
> > Also which ABI are you using? I have not been able to reproduce it
> > with EABI, but that may have been because I have a patched clang
> > I've been using to track down another issue.
> 
> I'm using whatever the default is in FreeBSD-CURRENT.  I've seen
> this consistently with both RaspberryPi and BeagleBone kernels
> for the last few weeks.
Ok, it's the old ABI. I note this function may be broken with EABI as
it make assumptions on the layout of each frame.


> If you see anything actually wrong with the "Broken version",
> I'm very curious.  I spent much of yesterday afternoon staring
> at it and cannot for the life of me see a problem with it.
I can't see anything different with the asm that can't be explained by
the added printf call.


> /* Broken version */
> c0519cec <stack_save>:
> void
> stack_save(struct stack *st)
> {
> c0519cec:       e92d4830        push    {r4, r5, fp, lr}

This stack layout is incorrect. It should store (from a low address to
high address) r4, r5, fp, ip, lr and pc. The unwind code following is
incorrect for this stack layout.

In your working code how deep is the stack you are printing? I
suspect you are getting lucky with the data on the stack.

Andrew