<div dir="ltr">Dear Dr. Gaisler,<div><br></div><div>There's something that I am getting stuck at while trying to debug an smp03 (<a href="https://git.rtems.org/rtems/tree/testsuites/smptests/smp03/init.c">https://git.rtems.org/rtems/tree/testsuites/smptests/smp03/init.c</a>) test suite with gdb running on sis.</div><div><br></div><div>I started sis with the command: </div><div>-------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>$ ./sparc-rtems5-sis -leon3 -m 4 -gdb</div><br> SIS - SPARC/RISCV instruction simulator 2.21, copyright Jiri Gaisler 2019<br> Bug-reports to <a href="mailto:jiri@gaisler.se">jiri@gaisler.se</a><br><br> LEON3 emulation enabled, 4 cpus online, delta 50 clocks<br><br>gdb: listening on port 1234 <br><div>-------------------------------------------------------------------------------------------------------------------<br></div><div>and gdb with the command:</div><div><br></div><div>-------------------------------------------------------------------------------------------------------------------<br></div><div>$ ./sparc-rtems5-gdb ~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe <br></div><div>.</div><div>.</div><div>.</div><div>Reading symbols from /home/richi/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe...<br>(gdb) target extended-remote localhost:1234<br>Remote debugging using localhost:1234<br>0x00000000 in ?? ()<br>(gdb) load<br>Loading section .text, size 0x20440 lma 0x40000000<br>Loading section .rtemsroset, size 0x90 lma 0x40020440<br>Loading section .data, size 0x690 lma 0x40028500<br>Start address 0x40000000, load size 133984<br>Transfer rate: 1063 KB/sec, 271 bytes/write.<br>(gdb) b _Scheduler_EDF_SMP_Get_highest_ready<br>Breakpoint 1 at 0x4000e620: _Scheduler_EDF_SMP_Get_highest_ready. (4 locations)<br>(gdb) continue<br>Continuing.<br><br>Breakpoint 1, _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 <_RTEMS_tasks_Objects+576>, <br> context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>)<br> at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151<br>151 self = _Scheduler_EDF_SMP_Get_self( context );<br>(gdb) stepi<br>0x4000e624 151 self = _Scheduler_EDF_SMP_Get_self( context );<br>(gdb) stepi<br>RBTree_Control_RB_MINMAX (val=-1, head=head@entry=0x4002bc74 <_Configuration_Scheduler_EDF_SMP_dflt+76>)<br> at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:37<br>37 {<br>(gdb) stepi<br>0x4001787c 37 {<br>(gdb) stepi<br>0x40017880 37 {<br>(gdb) stepi<br>0x40017884 37 {<br>(gdb) stepi<br>0x40017890 37 {<br>(gdb) stepi<br>0x40017894 37 {<br>(gdb) stepi<br>_RBTree_Minimum (tree=tree@entry=0x4002bc74 <_Configuration_Scheduler_EDF_SMP_dflt+76>)<br> at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/rbtreenext.c:39<br>39 }<br>(gdb) stepi<br>0x400178a0 39 }<br>(gdb) stepi<br>0x400178a4 39 }<br>(gdb) stepi<br>0x400178a8 39 }<br>(gdb) stepi<br>0x4000e628 in _Scheduler_EDF_SMP_Get_highest_ready (filter=0x40029000 <_RTEMS_tasks_Objects+576>, <br> context=0x4002bc28 <_Configuration_Scheduler_EDF_SMP_dflt>)<br> at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/scheduleredfsmp.c:151<br>151 self = _Scheduler_EDF_SMP_Get_self( context );<br>(gdb) stepi<br>164 <br>(gdb) stepi<br>0x4000e630 164 <br>(gdb) stepi<br>0x4000e634 164 <br>(gdb) stepi<br>0x4000e638 164 <br>(gdb) stepi<br>175 <br>(gdb) stepi<br>0x4000e694 175 <br>(gdb) <br></div><div>-------------------------------------------------------------------------------------------------------------------<br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Richi.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 12:55 PM Richi Dubey <<a href="mailto:richidubey@gmail.com">richidubey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks a lot! It is working now after I set appropriate breakpoints.<br>
<br>
On Tue, May 26, 2020 at 11:58 PM Jiri Gaisler <<a href="mailto:jiri@gaisler.se" target="_blank">jiri@gaisler.se</a>> wrote:<br>
><br>
><br>
> On 5/26/20 2:55 PM, Richi Dubey wrote:<br>
> > Hii,<br>
> ><br>
> > Thank you for your replies. I did not load the program before<br>
> > executing run on gdb. Now it works fine.<br>
> ><br>
> > However, I need your help with one more thing. When I run gdb with<br>
> > stepi or nexti to see how the code runs from the beginning to the end,<br>
> > gdb always ends up going in an infinite loop in hard_reset () at<br>
> > /home/richi/quick-start/src/rtems/c/src/lib/libbsp/sparc/leon3/../../../../../../bsps/sparc/shared/start/start.S:274<br>
> > while only executing the following commands:<br>
> ><br>
> > 371 std %g0,[%g2]<br>
> > (gdb)<br>
> > 372 add %g2,8,%g2<br>
> > (gdb)<br>
> > 373 cmp %g2,%g3<br>
> > (gdb)<br>
> > 374 bleu,a zerobss<br>
> > (gdb)<br>
> > 375 nop<br>
> ><br>
> ><br>
> > while the code in start.s is:<br>
> ><br>
> > zerobss:<br>
> > std %g0,[%g2]<br>
> > add %g2,8,%g2<br>
> > cmp %g2,%g3<br>
> > bleu,a zerobss<br>
> > nop<br>
> ><br>
> > ---------------------<br>
> ><br>
> > Can someone please tell me why gdb is not going back to the main file<br>
> > smpschededf02/init.c? Is it because we keep running start.s during the<br>
> > entire time of execution?<br>
><br>
> 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.<br>
><br>
><br>
> > And how do I run gdb while going through<br>
> > every instruction that init.c processes without getting stuck in an<br>
> > infinite loop like this. I set up a breakpoint at Init and everythings<br>
> > work fine but I am stilling missing the commands that were executed<br>
> > before Init.c was called. How do I see those?<br>
> ><br>
> > Also, If I use step with breakpoint at Init, it again goes into an<br>
> > infinite loop inside apbuart_polled.c with the following commands:<br>
> ><br>
> > 20 while ( (regs->status & APBUART_STATUS_TE) == 0 ) {<br>
> > (gdb)<br>
> > 22 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);<br>
> > (gdb)<br>
> > 23 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);<br>
> > (gdb)<br>
> > 24 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);<br>
> > (gdb)<br>
> > 25 __asm__ volatile ("nop"::); __asm__ volatile ("nop"::);<br>
> ><br>
> > Why is it running into an infinite loop?(If I use nexti, it does not<br>
> > run into an infinite loop as next does get inside functions, and Init<br>
> > finishes successfully).<br>
><br>
> 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.<br>
><br>
> Jiri.<br>
><br>
><br>
> ><br>
> > Thanks,<br>
> > Richi.<br>
> ><br>
> > On Tue, May 26, 2020 at 12:44 AM Jiri Gaisler <<a href="mailto:jiri@gaisler.se" target="_blank">jiri@gaisler.se</a>> wrote:<br>
> >><br>
> >> On 5/25/20 4:30 PM, Richi Dubey wrote:<br>
> >>> Hii everyone,<br>
> >>><br>
> >>> When I am executing smpschededf02.exe on my leon3 bsp running on<br>
> >>> sparc5 with sparc-rtems5-sis with -m 4 -leon3 option, it fails to<br>
> >>> execute properly.<br>
> >>><br>
> >>> I have built leon3 with --enable-smp option and I am guessing the<br>
> >>> execution fails because I don not see any output of the test and I can<br>
> >>> only see the following output:<br>
> >>> ---------------------------------------------<br>
> >>> ~/quick-start/rtems/5/bin$ ./sparc-rtems5-sis -leon3 -m 4<br>
> >>> ~/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe<br>
> >>><br>
> >>> SIS - SPARC/RISCV instruction simulator 2.21, copyright Jiri Gaisler 2019<br>
> >>> Bug-reports to <a href="mailto:jiri@gaisler.se" target="_blank">jiri@gaisler.se</a><br>
> >>><br>
> >>> LEON3 emulation enabled, 4 cpus online, delta 50 clocks<br>
> >>><br>
> >>> Loaded /home/richi/quick-start/build/leon3/sparc-rtems5/c/leon3/testsuites/smptests/smpschededf02.exe,<br>
> >>> entry 0x40000000<br>
> >>> cpu0> run<br>
> >>><br>
> >>><br>
> >>> *** BEGIN OF TEST SMPSCHEDEDF 2 ***<br>
> >>> *** TEST VERSION: 5.0.0.20a8361de4724658112ecd33c28fae82a15919f8<br>
> >>> *** TEST STATE: EXPECTED_PASS<br>
> >>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP<br>
> >>> *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)<br>
> >>><br>
> >>> *** END OF TEST SMPSCHEDEDF 2 ***<br>
> >>><br>
> >>> cpu 1 in error mode (tt = 0x80)<br>
> >>> 3491850 40016360: 91d02000 ta 0x0<br>
> >>> -------------------------------------------------------<br>
> >> Looks good to me, test passed OK and processor is halted by RTEMS.<br>
> >><br>
> >><br>
> >>> On running the program with gdb with extended-remote and debugging<br>
> >>> with sis, I am encountering the following error:<br>
> >>><br>
> >>> ----------------------<br>
> >>> (gdb) target extended-remote localhost:1234<br>
> >>> Remote debugging using localhost:1234<br>
> >>> 0x00000000 in ?? ()<br>
> >>> (gdb)<br>
> >>> ------------------------<br>
> >> This is indeed how you start remote debugging, but then you also have to do:<br>
> >><br>
> >> load<br>
> >><br>
> >> run<br>
> >><br>
> >> Then the program should run as expected ...<br>
> >><br>
> >><br>
> >> Jiri.<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> devel mailing list<br>
> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
</blockquote></div>