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