[Sound-open-firmware] [EXT] Re: Stack alignment issues with XCC?

[Paul Olaru]

No, the exception cause is accessing an unaligned memory region,
and shifting the stack pointer like that fixes it. For some reason
epc1 points after an "enter" instruction as well.

On GCC the stack is still unaligned but since GCC doesn't vectorize
anything (XCC has vector operations for the Volume component
in my case, although epc1 doesn't point there) everything else
is fine.

Without alignment I see the stack still being misaligned when entering
the IRQ handler for DMA multi channel domain; fixing the alignment
as early as in my PR still preserves it at that point.

Also I read that Xtensa ABI requires stacks to be aligned to 16 bytes
and compilers can just assume it's already aligned. Can't confirm the
source for that claim yet but given my observations it seems likely to
be in fact true. As such the compiler assumes the stack pointer is aligned
and when allocating on-stack structures which require an alignment of
16 or less it doesn't insert any further alignment code.

I will test again on master, trying to add more and more prints in the code
to see exactly where it crashes the DSP and report back. But this is
my current observation, aligning the stack there keeps the stack
aligned throughout and fixes my issue.

-----Original Message-----
From: Liam Girdwood <liam.r.girdwood at linux.intel.com> 
Sent: Wednesday, November 20, 2019 5:02 PM
To: Paul Olaru <paul.olaru at nxp.com>; sound-open-firmware at alsa-project.org
Subject: Re: [Sound-open-firmware] [EXT] Re: Stack alignment issues with XCC?

Caution: EXT Email

On Wed, 2019-11-20 at 14:10 +0000, Paul Olaru wrote:
> Didn't test the emulator (I still have trouble with that).
>
> If other interrupts caused problems wouldn't I be able to see more
> logs
> than the one related to registering the DMA interrupt?

If IRQ handling was broken in general then I'd expect you would see
similar errors for SW or Timer IRQs.

>
> Also (see my draft/hack PR, #2111) if I force-align the stack within
> the
> irq_steer handler I don't get any panics further on. Although it may
> very well be possible that the compiler doesn't vectorize any
> instruction
> in any of the functions directly or indirectly called from such an
> interrupt
> (there is nothing to vectorize?) and thus the stack may still be
> misaligned
> but in those cases it doesn't matter.

I dont think there is anything to vectorize in the handlers, it's
mostly HAL assembler before it jumps into C code.

My general suspicion is that something is corrupting stack or a ptr in
your DMA code somewhere that's killing FW when the DMA IRQs. The
alignment is probably moving any corruption to an unrelated data
section not used in the IRQ handler ?

Liam

>
> -----Original Message-----
> From: Liam Girdwood <liam.r.girdwood at linux.intel.com>
> Sent: Wednesday, November 20, 2019 1:09 PM
> To: Paul Olaru <paul.olaru at nxp.com>;
> sound-open-firmware at alsa-project.org
> Subject: [EXT] Re: [Sound-open-firmware] Stack alignment issues with
> XCC?
>
> Caution: EXT Email
>
> On Tue, 2019-11-19 at 15:33 +0000, Paul Olaru wrote:
> > Hello, I'm trying to begin doing all my builds with XCC for testing
> > and, besides one issue where I need to
> > manually insert stack alignment code in the IRQ handling function
> > for
> > the DMA domain it seems to work.
> > Also, if I align the stack within my IRQ_STEER handler it remains
> > aligned for the domain handler just fine.
> >
> > My question is, why within irq_handler (see
> > src/drivers/imx/interrupt.c, function begins around line 275)
> > the stack is not aligned? Did you also encounter this issue on
> > other
> > platforms? And is there any good
> > solution other than that bit of inline assembly that just force-
> > aligns the stack pointer when entering the
> > cascaded IRQ handler?
> >
>
> Never encountered this on Intel platforms. It could be another issue
> that shows up when handling an IRQ ?
>
> Does the emulator shed any light on this ?
>
> > Without this code I seem to get panics with an alignment exception,
> > the address pointing within an
> > Interrupt stack and epc0 not being correct (I think I need to
> > investigate that as well but that's a
> > low-priority issue).
>
> Could be corruption somewhere else ? I guess the timer IRQs and SW
> IRQs
> work fine without the alignment ?
>
> Liam
> >
> > Compiler version for reference (in case there is a known issue I'm
> > not aware of):
> >
> > xt-xcc -v
> > xt-xcc version 11.0.4
> > Thread model: single
> > _______________________________________________
> > Sound-open-firmware mailing list
> > Sound-open-firmware at alsa-project.org
> >
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.alsa-project.org%2Fmailman%2Flistinfo%2Fsound-open-firmware&data=02%7C01%7Cpaul.olaru%40nxp.com%7Cc9a87b655c234942f4a608d76dca9d07%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637098589315379754&sdata=ZGO%2B9XCbASjyuiU3JVO7IS00zL8TroOYoo2P0yfQe6M%3D&reserved=0
>
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.alsa-project.org%2Fmailman%2Flistinfo%2Fsound-open-firmware&data=02%7C01%7Cpaul.olaru%40nxp.com%7Cc9a87b655c234942f4a608d76dca9d07%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637098589315379754&sdata=ZGO%2B9XCbASjyuiU3JVO7IS00zL8TroOYoo2P0yfQe6M%3D&reserved=0