Need help in debugging a testsuite over qemu and gdb

[Gedare Bloom]

On Tue, Aug 11, 2020 at 9:07 AM Richi Dubey <richidubey at gmail.com> wrote:
>>
>> If you hit this break point, try to use
>> bt
>> and then set a conditional break point to the offending function, reset
>> the target, and run again.
>
> I will use this. Thanks again.
>
>> It depends on the correctness of the program call stack though, so you may on
>> occasion find the bt is corrupt/fails.
>
> Yes, That is exactly what happened. Why does this happen though? What is meant by backtrace or the function call stack being corrupted? How can a stack that stores the name of series of function that call one another get corrupt?
>
The return address of each caller is stored on the stack. GDB uses
those return addresses (and frame size information) to determine the
backtrace. If something smashes the stack and overwrites the return
address, then you can't get a backtrace.

> ------------------------------------------------------------
> Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
> 70 sub sp, #MORE_CONTEXT_SIZE
> (gdb) bt
> #0  _ARMV4_Exception_data_abort_default () at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
> #1  0x00118bfe in _Scheduler_strong_APA_Get_lowest_scheduled (context=0x200620 <_Configuration_Scheduler_strong_APA_dflt>, filter_base=0x201910 <_RTEMS_tasks_Objects+600>) at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c:288
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The end of the bt may not actually be corruption, since you're
debugging a kernel there isn't always a clean ending. Here though, it
is suspicious. You should have some notion of what function called
_Scheduler_strong_APA_Get_lowest_scheduled(). Now though you can set
your breakpoint at this function, do a bt, and track through what the
function does. It may not be the first time it gets called that leads
the exception though. So you may have some trial and error.

> ------------------------------------------------------------
>
>
> On Tue, Aug 11, 2020 at 6:45 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Tue, Aug 11, 2020 at 4:30 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> >
>> > On 11/08/2020 11:40, Richi Dubey wrote:
>> > > (gdb) continue
>> > > Continuing.
>> > >
>> > > Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at
>> > > /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
>> >
>> > If you hit this break point, try to use
>> >
>> > bt
>> >
>> > and then set a conditional break point to the offending function, reset
>> > the target, and run again.
>> >
>>
>> Yes, the backtrace is most important at this point, because you are
>> still trying to figure out how you got to the exception. It depends on
>> the correctness of the program call stack though, so you may on
>> occasion find the bt is corrupt/fails. In such cases, you may need to
>> set breakpoints during the RTEMS initialization/startup sequence. The
>> boot_card() is a good place to start from in those cases.
>>
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel