This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What should a CPU simulator support?
- From: Jim Blandy <jimb at codesourcery dot com>
- To: s88 <dave dot tw at gmail dot com>
- Cc: "Wenbo Yang" <wenbo dot yang at simplnano dot com>, gdb at sourceware dot org
- Date: Thu, 05 Jul 2007 14:31:59 -0700
- Subject: Re: What should a CPU simulator support?
- References: <468C57AE.8020801@simplnano.com> <m3d4z64q8w.fsf@codesourcery.com> <c9d32f760707051300r192ea70bj3edcfc00892c5714@mail.gmail.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.