<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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 ...</p>
<p>Jiri.<br>
</p>
<div class="moz-cite-prefix">On 7/2/20 10:32 AM, Richi Dubey wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAQOZwzKGBWX5YvLnGu9rCVPXLfmcCGmhZMyCP5jRi1MbnihHw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Yeah, this makes a lot of sense.
<div>Mr. Huber also told me a similar story about qemu using -O0
optimizations which are easier to debug. </div>
<div><br>
</div>
<div>Thank you.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jul 1, 2020 at 8:03 PM
Gedare Bloom <<a href="mailto:gedare@rtems.org"
moz-do-not-send="true">gedare@rtems.org</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">On
Wed, Jul 1, 2020 at 5:32 AM Richi Dubey <<a
href="mailto:richidubey@gmail.com" target="_blank"
moz-do-not-send="true">richidubey@gmail.com</a>> wrote:<br>
><br>
> Dear Dr. Gaisler,<br>
><br>
> 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"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://git.rtems.org/rtems/tree/testsuites/smptests/smp03/init.c</a>)
test suite with gdb running on sis.<br>
><br>
> I started sis with the command:<br>
>
-------------------------------------------------------------------------------------------------------------------<br>
><br>
> $ ./sparc-rtems5-sis -leon3 -m 4 -gdb<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" moz-do-not-send="true">jiri@gaisler.se</a><br>
><br>
> LEON3 emulation enabled, 4 cpus online, delta 50 clocks<br>
><br>
> gdb: listening on port 1234<br>
>
-------------------------------------------------------------------------------------------------------------------<br>
> and gdb with the command:<br>
><br>
>
-------------------------------------------------------------------------------------------------------------------<br>
> $ ./sparc-rtems5-gdb
~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites/smptests/smp03.exe<br>
> .<br>
> .<br>
> .<br>
> 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>
>
-------------------------------------------------------------------------------------------------------------------<br>
> 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.<br>
><br>
<br>
This can happen because of compiler optimizations. The order
of the<br>
assembly instructions in the program does not need to match
exactly<br>
the order in the source code, and some source lines might not
have any<br>
assembly associated with them. You can turn off optimization,
or you<br>
can compare the debug execution with the assembly program, to
try to<br>
get some more insight.<br>
<br>
> Thanks,<br>
> Richi.<br>
><br>
> On Fri, May 29, 2020 at 12:55 PM Richi Dubey <<a
href="mailto:richidubey@gmail.com" target="_blank"
moz-do-not-send="true">richidubey@gmail.com</a>> wrote:<br>
>><br>
>> 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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">devel@rtems.org</a><br>
>> > >> <a
href="http://lists.rtems.org/mailman/listinfo/devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> ><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank"
moz-do-not-send="true">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>