Need help in debugging a testsuite over qemu and gdb

[Richi Dubey]

>
> 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?

------------------------------------------------------------
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?)
------------------------------------------------------------


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200811/9db457f2/attachment-0001.html>