Need help to execute/debug smpschededf02.exe on leon3

Gedare Bloom gedare at rtems.org
Wed Jul 1 14:33:26 UTC 2020


On Wed, Jul 1, 2020 at 5:32 AM Richi Dubey <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
>
>  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> 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> 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> 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
>> > >>>
>> > >>>  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
>> > >> http://lists.rtems.org/mailman/listinfo/devel
>> >
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list