Re: [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

> In any case, unless you have any information that suggests that GCC in
> Thumb2 mode can be coerced into managing the frame pointer in a way
> that allows us to do something similar in EDK2, I am going to stick
> with my assertion that this is not currently possible on ARM.

I think it's not possible because they enable ARM_UNWIND when compiling
a THUMB2_KERNEL.

porting libunwind would be hard because of UEFI's architecture. every *.efi
would need a section with unwind information, and I don't even know if the
spec allows additional sections.

Thanks
Michael

On Fri, Sep 9, 2016 at 3:08 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 7 September 2016 at 12:32, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > On 7 September 2016 at 12:25, Michael Zimmermann
> > <sigmaepsilon92@gmail.com> wrote:
> >>> However, looking at this
> >>> code, this is still not sufficient to find the *next* frame pointer on
> >>> the stack.
> >> are you sure about that? this code looks like it does just that:
> >> https://github.com/torvalds/linux/blob/master/arch/arm/
> kernel/stacktrace.c
> >>
> >
> > First of all, that comment makes little sense:
> >
> > * With framepointer enabled, a simple function prologue looks like this:
> > * mov ip, sp
> > * stmdb sp!, {fp, ip, lr, pc}
> >
> > I assume this should be
> >
> > stmdb sp!, {fp, ip, lr}
> >
> > * sub fp, ip, #4
> > *
> > * A simple function epilogue looks like this:
> > * ldm sp, {fp, sp, pc}
> >
>
> OK, I spoke a bit too soon. The 'pop' does not actually increment the
> stack pointer, so while the push does make sense (and pushing the pc
> in addition is just informational), the pop should actually be
> implemented as
>
> ldm sp, {fp, sp, lr}
>
> ... do other stuff including incrementing the sp to its original value ...
>
> bx lr
>
> In any case, unless you have any information that suggests that GCC in
> Thumb2 mode can be coerced into managing the frame pointer in a way
> that allows us to do something similar in EDK2, I am going to stick
> with my assertion that this is not currently possible on ARM.
>
> Thanks,
> Ard.
>