Great advice. I'll keep these points in my mind. Thanks. On Tue, Aug 11, 2020 at 10:27 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Aug 11, 2020 at 9:07 AM Richi Dubey <richidu...@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 <ged...@rtems.org> wrote: > >> > >> On Tue, Aug 11, 2020 at 4:30 AM Sebastian Huber > >> <sebastian.hu...@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@rtems.org > >> > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
