SPARC-RTEMS5-GDB and RTEMS Fatal error !

[Chris Johns]

On 16/4/19 5:25 am, Michel Macena wrote:
> Hi, I have compiled a code for an ERC32 target board and loaded it using gdb,
> the code:
> 
>     #include <bsp.h>
>     #include <stdlib.h>
>     #include <stdio.h>
> 
> 
>     rtems_task Init(
>       rtems_task_argument ignored
>     )
>     {
> 
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
>         printf( "Hello World Michel\n" );
> 
>     }
> 
>     /* configuration information */
> 
>     /* NOTICE: the clock driver is explicitly disabled */
>     #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
>     #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> 
>     #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>     #define CONFIGURE_MAXIMUM_TASKS 1
> 
>     #define CONFIGURE_INIT
> 
>     #include <rtems/confdefs.h>
> 
> 
> the gdb commands:
> 
>     sparc-rtems5-gdb /home/inpe/rtems_exemplos/compile_test/hello_test/hello_exp.exe
>     set serial baud 19200
>     target extended-remote /dev/ttyS0

OK, you are using a tty I so assume this is a real board. Nice.

>     load
>     run

Yes GDB will report the program is already running as it is, your target is
powered on and running because you can attach to it via the remote target command.

> It loads the program perfectly, but I try the command "run" it says
> that the program is already running. So I closed the session
> and started a new one.  The session:
> 
>     sparc-rtems5-gdb /home/inpe/rtems_exemplos/compile_test/hello_test/hello_exp.exe
>     GNU gdb (GDB) 8.2.1
>     Copyright (C) 2018 Free Software Foundation, Inc.
>     License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>     This is free software: you are free to change and redistribute it.
>     There is NO WARRANTY, to the extent permitted by law.
>     Type "show copying" and "show warranty" for details.
>     This GDB was configured as "--host=i686-linux-gnu --target=sparc-rtems5".
>     Type "show configuration" for configuration details.
>     For bug reporting instructions, please see:
>     <http://www.gnu.org/software/gdb/bugs/>.
>     Find the GDB manual and other documentation resources online at:
>         <http://www.gnu.org/software/gdb/documentation/>.
> 
>     For help, type "help".
>     Type "apropos word" to search for commands related to "word"...
>     Reading symbols from
>     /home/inpe/rtems_exemplos/compile_test/hello_test/hello_exp.exe...done.
>     (gdb) set serial baud 19200
>     (gdb) target extended-remote /dev/ttyS0
>     Remote debugging using /dev/ttyS0
>     trap_table ()
>         at
>     /home/inpe/masters_project/src/rtems/c/src/lib/libbsp/sparc/erc32/../../../../../../bsps/sparc/shared/start/start.S:107
>     107      RTRAP( 0, SYM(hard_reset) );                  ! 00 reset trap
>     (gdb) cont
>     Continuing.
>     [Inferior 1 (Remote target) exited normally]
>     ../../gdb-8.2.1/gdb/thread.c:93: internal-error: thread_info*
>     inferior_thread(): Assertion `tp' failed.
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
>     Quit this debugging session? (y or n) y
> 
>     This is a bug, please report it.  For instructions, see:
>     <http://www.gnu.org/software/gdb/bugs/>.
> 
>     ../../gdb-8.2.1/gdb/thread.c:93: internal-error: thread_info*
>     inferior_thread(): Assertion `tp' failed.
> 
> 
> When I use the command "cont" the program ran, but his was the ERC32 board
> console output:
> 
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>     Hello World Michel
>      
>     *** FATAL ***
>     fatal source: 0 (INTERNAL_ERROR_CORE)
>     fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)
>     RTEMS version: 5.0.0.0a9b45132c0144c1dc4b6b828a68608c21397ca4
>     RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
>     9a3e12e5820918057633798c3fe2a1f952fb4e56, Newlib 1d35a003f)
>     executing thread ID: 0x08a010001
>     executing thread name: UI1
> 

Excellent, this is all normal and expected.

> It seems that that the code works but I don't get why the "FATAL" and also the
> "tp" error in GDB.
> Do you know what may be happening ?

Let me explain....

GDB needs to attach to an existing program or process. What you are observing is
some of what is happening to do this.

When you debug a native program on Linux, FreeBSD, Windows etc you start GDB
with the executable file and enter the `run` command and the program runs. To do
this GDB asks the host OS back-end support built into GDB to start, attach and
then execute your program. The back-end will `exec()` the executable, attach GDB
to the now existing process and start it executing.

GDB has another mode of working where it can attach to an existing process on
Linux, etc. Have a look at the command line help for GDB using something like
`gdb --help`. To attach you start GDB with the executable file and the process
id. GDB will attach to the process, halt it and present you with its current
state. You do not use the `run` command in this case because the process is
already running. The process id passed on the command line could be considered a
short hand telling GDB the target is a local process.

Think of your target hardware as the process and powering on the target is
starting it. You then need to attach to it. This is similar to attaching GDB to
a running process. As your target hardware is remote, that is not on the host
machine running GDB you need to use the `target remote` command to attach to the
"remote process" or you target hardware. When attached GDB presents you with the
halted state of your target and you are now ready to set breakpoints, inspect
variables and continue executing.

With an embedded GDB session the `load` command is sometimes used. This is an
extra step to download the executable image to your remote target. GDB needs to
be attached to your target to do this. Think of this step as filling the memory
with the code and initialised data.

Chris