Need help to execute/debug smpschededf02.exe on leon3

[Jiri Gaisler]

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