Need help to execute/debug smpschededf02.exe on leon3
Richi Dubey
richidubey at gmail.com
Wed Jul 1 11:32:07 UTC 2020
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.
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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200701/53d5ee30/attachment-0001.html>
More information about the devel
mailing list