Re: What should a CPU simulator support?

[Jim Blandy <jimb at codesourcery dot com>]

s88 <dave.tw@gmail.com> writes:
> Let me try to define my question clearly.
>
> I have a ARM simulator. I want this simulator to be a target of the gdb.
> And I write a gdb_stub for this simulator,too.
> I'll use the remote debugging to connect this target (ARM simulator) in the way
> of "target remote IP_ADDRESS:PORT".
> So, I want to make sure if the ARM simulator support single instruction
> execution. It should handle the gdb's command by the gdb stub?

There are two ways for GDB to connect to a simulator:

- You can make the simulator into a '.a' library, have it implement
  the interface in include/gdb/remote-sim.h, and link it directly with
  GDB.  Then the GDB 'target sim' command will initialize the
  simulator, and subsequent 'run', 'continue', 'step' (etc.) commands
  will apply to it.

  This is simplest for the end user: no separate program to start up,
  no separate program file to find, and so on.

- You can make the simulator into a server for the GDB remote
  protocol.  Here, the interface to be implemented is described in the
  "Remote Protocol" appendix of the GDB manual.  As that appendix
  says:

       For any COMMAND not supported by the stub, an empty response
    (`$#00') should be returned.  That way it is possible to extend the
    protocol.  A newer GDB can tell if a packet is supported based on that
    response.

       A stub is required to support the `g', `G', `m', `M', `c', and `s'
    COMMANDs.  All other COMMANDs are optional.

  Note that the 's' (single-step) command is required.

  If you make your simulator speak the remote protocol on its stdin
  and stdout, then your user can use the new 'target remote | COMMAND'
  syntax to run the simulator, which simplifies things a bit.