Will keep this in mind. Thanks. On Thu, Jul 2, 2020 at 4:05 PM Jiri Gaisler <j...@gaisler.se> wrote:
> Note that single-stepping of smp code at instruction-level might affect > the timing of the execution. During single-stepping, only one core is > advanced while the others stay halted. If you are trying to catch a race > condition then the timing impact might change the program behavior. Shorter > bursts of single-stepping will usually not have any side-effect as the > default execution slot for each cpu is 50 clocks, but it might be good be > aware of this behavior ... > > Jiri. > On 7/2/20 10:32 AM, Richi Dubey wrote: > > Yeah, this makes a lot of sense. > Mr. Huber also told me a similar story about qemu using -O0 optimizations > which are easier to debug. > > Thank you. > > On Wed, Jul 1, 2020 at 8:03 PM Gedare Bloom <ged...@rtems.org> wrote: > >> On Wed, Jul 1, 2020 at 5:32 AM Richi Dubey <richidu...@gmail.com> wrote: >> > >> > Dear Dr. Gaisler, >> > >> > There's something that I am getting stuck at while trying to debug an >> smp03 (https://git.rtems.org/rtems/tree/testsuites/smptests/smp03/init.c) >> test suite with gdb running on sis. >> > >> > I started sis with the command: >> > >> ------------------------------------------------------------------------------------------------------------------- >> > >> > $ ./sparc-rtems5-sis -leon3 -m 4 -gdb >> > >> > SIS - SPARC/RISCV instruction simulator 2.21, copyright Jiri Gaisler >> 2019 >> > Bug-reports to j...@gaisler.se >> > >> > LEON3 emulation enabled, 4 cpus online, delta 50 clocks >> > >> > gdb: listening on port 1234 >> > >> ------------------------------------------------------------------------------------------------------------------- >> > and gdb with the command: >> > >> > >> ------------------------------------------------------------------------------------------------------------------- >> > $ ./sparc-rtems5-gdb >> ~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe >> > . >> > . >> > . >> > Reading symbols from >> /home/richi/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe... >> > (gdb) target extended-remote localhost:1234 >> > Remote debugging using localhost:1234 >> > 0x00000000 in ?? () >> > (gdb) load >> > Loading section .text, size 0x20440 lma 0x40000000 >> > Loading section .rtemsroset, size 0x90 lma 0x40020440 >> > Loading section .data, size 0x690 lma 0x40028500 >> > Start address 0x40000000, load size 133984 >> > Transfer rate: 1063 KB/sec, 271 bytes/write. >> > (gdb) b _Scheduler_EDF_SMP_Get_highest_ready >> > Breakpoint 1 at 0x4000e620: _Scheduler_EDF_SMP_Get_highest_ready. (4 >> locations) >> > (gdb) continue >> > Continuing. >> > >> > Breakpoint 1, _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 >> <_RTEMS_tasks_Objects+576>, >> > context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>) >> > at >> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151 >> > 151 self = _Scheduler_EDF_SMP_Get_self( context ); >> > (gdb) stepi >> > 0x4000e624 151 self = _Scheduler_EDF_SMP_Get_self( context ); >> > (gdb) stepi >> > RBTree_Control_RB_MINMAX (val=-1, head=head@entry=0x4002bc74 >> <_Configuration_Scheduler_EDF_SMP_dflt+76>) >> > at >> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:37 >> > 37 { >> > (gdb) stepi >> > 0x4001787c 37 { >> > (gdb) stepi >> > 0x40017880 37 { >> > (gdb) stepi >> > 0x40017884 37 { >> > (gdb) stepi >> > 0x40017890 37 { >> > (gdb) stepi >> > 0x40017894 37 { >> > (gdb) stepi >> > _RBTree_Minimum (tree=tree@entry=0x4002bc74 >> <_Configuration_Scheduler_EDF_SMP_dflt+76>) >> > at >> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:39 >> > 39 } >> > (gdb) stepi >> > 0x400178a0 39 } >> > (gdb) stepi >> > 0x400178a4 39 } >> > (gdb) stepi >> > 0x400178a8 39 } >> > (gdb) stepi >> > 0x4000e628 in _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 >> <_RTEMS_tasks_Objects+576>, >> > context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>) >> > at >> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151 >> > 151 self = _Scheduler_EDF_SMP_Get_self( context ); >> > (gdb) stepi >> > 164 >> > (gdb) stepi >> > 0x4000e630 164 >> > (gdb) stepi >> > 0x4000e634 164 >> > (gdb) stepi >> > 0x4000e638 164 >> > (gdb) stepi >> > 175 >> > (gdb) stepi >> > 0x4000e694 175 >> > (gdb) >> > >> ------------------------------------------------------------------------------------------------------------------- >> > Now I can't figure out why gdb won't show me the next instruction after >> 151 self = _Scheduler_EDF_SMP_Get_self( context );? Why is it jumping to >> instruction 164 and later to 175? What might be going wrong? Please let me >> know. >> > >> >> This can happen because of compiler optimizations. The order of the >> assembly instructions in the program does not need to match exactly >> the order in the source code, and some source lines might not have any >> assembly associated with them. You can turn off optimization, or you >> can compare the debug execution with the assembly program, to try to >> get some more insight. >> >> > Thanks, >> > Richi. >> > >> > On Fri, May 29, 2020 at 12:55 PM Richi Dubey <richidu...@gmail.com> >> wrote: >> >> >> >> Thanks a lot! It is working now after I set appropriate breakpoints. >> >> >> >> On Tue, May 26, 2020 at 11:58 PM Jiri Gaisler <j...@gaisler.se> wrote: >> >> > >> >> > >> >> > On 5/26/20 2:55 PM, Richi Dubey wrote: >> >> > > Hii, >> >> > > >> >> > > Thank you for your replies. I did not load the program before >> >> > > executing run on gdb. Now it works fine. >> >> > > >> >> > > However, I need your help with one more thing. When I run gdb with >> >> > > stepi or nexti to see how the code runs from the beginning to the >> end, >> >> > > gdb always ends up going in an infinite loop in hard_reset () at >> >> > > >> /home/richi/quick-start/src/rtems/c/src/lib/libbsp/sparc/leon3/../../../../../../bsps/sparc/shared/start/start.S:274 >> >> > > while only executing the following commands: >> >> > > >> >> > > 371 std %g0,[%g2] >> >> > > (gdb) >> >> > > 372 add %g2,8,%g2 >> >> > > (gdb) >> >> > > 373 cmp %g2,%g3 >> >> > > (gdb) >> >> > > 374 bleu,a zerobss >> >> > > (gdb) >> >> > > 375 nop >> >> > > >> >> > > >> >> > > while the code in start.s is: >> >> > > >> >> > > zerobss: >> >> > > std %g0,[%g2] >> >> > > add %g2,8,%g2 >> >> > > cmp %g2,%g3 >> >> > > bleu,a zerobss >> >> > > nop >> >> > > >> >> > > --------------------- >> >> > > >> >> > > Can someone please tell me why gdb is not going back to the main >> file >> >> > > smpschededf02/init.c? Is it because we keep running start.s during >> the >> >> > > entire time of execution? >> >> > >> >> > zerobss: function is not infinite, it just loops for many thousands >> (millions) iterations while it clears the bss segment. SIngle-stepping >> though zerobss: will obviously take a VERY long time, so put a breakpoint >> on somewhere after it has been called. >> >> > >> >> > >> >> > > And how do I run gdb while going through >> >> > > every instruction that init.c processes without getting stuck in an >> >> > > infinite loop like this. I set up a breakpoint at Init and >> everythings >> >> > > work fine but I am stilling missing the commands that were executed >> >> > > before Init.c was called. How do I see those? >> >> > > >> >> > > Also, If I use step with breakpoint at Init, it again goes into an >> >> > > infinite loop inside apbuart_polled.c with the following commands: >> >> > > >> >> > > 20 while ( (regs->status & APBUART_STATUS_TE) == 0 ) { >> >> > > (gdb) >> >> > > 22 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::); >> >> > > (gdb) >> >> > > 23 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::); >> >> > > (gdb) >> >> > > 24 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::); >> >> > > (gdb) >> >> > > 25 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::); >> >> > > >> >> > > Why is it running into an infinite loop?(If I use nexti, it does >> not >> >> > > run into an infinite loop as next does get inside functions, and >> Init >> >> > > finishes successfully). >> >> > >> >> > The loop is not infinite, it just loops while waiting for the UART >> transmitter to send out a character. nexti puts a breakpoint after the >> loop, that is why it finishes. >> >> > >> >> > Jiri. >> >> > >> >> > >> >> > > >> >> > > Thanks, >> >> > > Richi. >> >> > > >> >> > > On Tue, May 26, 2020 at 12:44 AM Jiri Gaisler <j...@gaisler.se> >> wrote: >> >> > >> >> >> > >> On 5/25/20 4:30 PM, Richi Dubey wrote: >> >> > >>> Hii everyone, >> >> > >>> >> >> > >>> When I am executing smpschededf02.exe on my leon3 bsp running on >> >> > >>> sparc5 with sparc-rtems5-sis with -m 4 -leon3 option, it fails >> to >> >> > >>> execute properly. >> >> > >>> >> >> > >>> I have built leon3 with --enable-smp option and I am guessing the >> >> > >>> execution fails because I don not see any output of the test and >> I can >> >> > >>> only see the following output: >> >> > >>> --------------------------------------------- >> >> > >>> ~/quick-start/rtems/5/bin$ ./sparc-rtems5-sis -leon3 -m 4 >> >> > >>> >> ~/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe >> >> > >>> >> >> > >>> SIS - SPARC/RISCV instruction simulator 2.21, copyright Jiri >> Gaisler 2019 >> >> > >>> Bug-reports to j...@gaisler.se >> >> > >>> >> >> > >>> LEON3 emulation enabled, 4 cpus online, delta 50 clocks >> >> > >>> >> >> > >>> Loaded >> /home/richi/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe, >> >> > >>> entry 0x40000000 >> >> > >>> cpu0> run >> >> > >>> >> >> > >>> >> >> > >>> *** BEGIN OF TEST SMPSCHEDEDF 2 *** >> >> > >>> *** TEST VERSION: 5.0.0.20a8361de4724658112ecd33c28fae82a15919f8 >> >> > >>> *** TEST STATE: EXPECTED_PASS >> >> > >>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP >> >> > >>> *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), >> Newlib fbaa096) >> >> > >>> >> >> > >>> *** END OF TEST SMPSCHEDEDF 2 *** >> >> > >>> >> >> > >>> cpu 1 in error mode (tt = 0x80) >> >> > >>> 3491850 40016360: 91d02000 ta 0x0 >> >> > >>> ------------------------------------------------------- >> >> > >> Looks good to me, test passed OK and processor is halted by RTEMS. >> >> > >> >> >> > >> >> >> > >>> On running the program with gdb with extended-remote and >> debugging >> >> > >>> with sis, I am encountering the following error: >> >> > >>> >> >> > >>> ---------------------- >> >> > >>> (gdb) target extended-remote localhost:1234 >> >> > >>> Remote debugging using localhost:1234 >> >> > >>> 0x00000000 in ?? () >> >> > >>> (gdb) >> >> > >>> ------------------------ >> >> > >> This is indeed how you start remote debugging, but then you also >> have to do: >> >> > >> >> >> > >> load >> >> > >> >> >> > >> run >> >> > >> >> >> > >> Then the program should run as expected ... >> >> > >> >> >> > >> >> >> > >> Jiri. >> >> > >> >> >> > >> >> >> > >> _______________________________________________ >> >> > >> 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 >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
