Need help in debugging a testsuite over qemu and gdb

[Richi Dubey]

Great advice. I'll keep these points in my mind. Thanks.

On Tue, Aug 11, 2020 at 10:27 PM Gedare Bloom <gedare at rtems.org> wrote:

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