Thanks a lot! It is working now after I set appropriate breakpoints.
On Tue, May 26, 2020 at 11:58 PM Jiri Gaisler <j...@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 <j...@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 j...@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@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
