Need help to execute/debug smpschededf02.exe on leon3

Jiri Gaisler jiri at gaisler.se
Thu Jul 2 10:35:20 UTC 2020


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 <gedare at rtems.org <mailto:gedare at rtems.org>> wrote:
>
>     On Wed, Jul 1, 2020 at 5:32 AM Richi Dubey <richidubey at gmail.com <mailto:richidubey at 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 jiri at gaisler.se <mailto:jiri at 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 at 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 at 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 <richidubey at gmail.com <mailto:richidubey at 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 <jiri at gaisler.se <mailto:jiri at 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 <jiri at gaisler.se <mailto:jiri at 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 jiri at gaisler.se <mailto:jiri at 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 at rtems.org <mailto:devel at rtems.org>
>     >> > >> http://lists.rtems.org/mailman/listinfo/devel
>     >> >
>     >
>     > _______________________________________________
>     > devel mailing list
>     > devel at rtems.org <mailto: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/20200702/9694d3e7/attachment-0001.html>


More information about the devel mailing list