The gdb-remote object will get a name assigned automatically unless one is specified using name.
Processors to connect to should be specified using the cpu or the cpus argument, the GDB session will follow the execution on that particular processor(s). It will see all code that runs on selected processor(s): user processes, operating system, hypervisor, everything. If no cpu or cpus argument is given the current cpu object will be used.
The architecture argument can be used to specify a particular architecture for the GDB session. It should be the architecture name used by Simics and not the GDB architecture name. For example, if you are debugging a 32-bit program on a 64-bit x86 processor, you may want to specify x86 as architecture and run set architecture i386 in GDB before connecting. For 64-bit PowerPC platforms set this argument to ppc32 to debug a 32-bit program. If not given, the architecture of a specified processor will be used. Note that when using multiple cpus they all should be of the same architecture.
The -disallow-remote-commands argument will prevent the client from using the monitor command, which sends a qRcmd message, to perform any Simics CLI command over the remote connection.
In GDB, use one of the commands target remote host:port or target extended-remote host:port to connect to Simics. The latter is required when connecting to multiple cpus.
Upon connection GDB assumes that the simulation is paused. GDB also assumes that it has full 'run control' (continue, step, next, etc.) and will be confused if simulation also is controlled by other means, such as using Simics commands.
When connecting to multiple cpus, use GDB inferiors to connect to additional cpus. To attach to a second cpu run the following commands in gdb:
add-inferior
inferior 2
attach 2
The cpus enumeration can be listed using info os processes in gdb.
When using multicore one should use set schedule-multiple on to tell gdb to continue on all processes (cpus).