Re: Infinite Stack Unwinding ARM

Johannes Stoelp <[email protected]> writes:

> I understand that gdb does not have to understand every hand written
> assembler routine, but I would like to emphasize that gdb in this
> particular case ends in an "infinite" loop printing the backtrace line
> by line (I put infinite in quotes because the loop is limited by the
> lower boundary of an integer).
> I would expect gdb to be more defensive in this case and either try
> other unwinding techniques like backward unwinding (from bottom up) or
> just stop unwinding because of to less information.

Don't understand what do you mean by "backward unwinding".  IIUC,
el1_irq are vector entry points, so I expect GDB unwinding stops on
el1_irq, but I want to check with kernel people to see their
expectation.  Can you post me the backtrace, as a sample output?
We may end up with having some Linux kernel specific stuff, and this
should fall in "Linux kernel debugging for aarch64".  Note that we had
patches for general Linux kernel debugging
https://sourceware.org/ml/gdb-patches/2017-03/msg00268.html (well, I
need to review them soon)

> In my understanding situations like this can also occur when the stack
> gets corrupted. There I would also expect gdb to not end in an
> infinite loop since gdb is intended to analyze the non-expected
> situation.
>
> One other question that came up by comparing the arm and the aarch64 analyzer:
>     * Is there a special reason/trick why the arm analyzer
> (gdb/arm-tdep.c:arm_analyze_prologue(...)) skips instructions that it
> doesn't recognize while the aarch64 analyzer
> (gdb/aarch64-tdep.c:aarch64_prologue_analyzer(...)) stops when the
> first unrecognized instruction is hit?

I don't see any reason here, just because they are two different
architectures.

-- 
Yao (齐尧)