Re: What should a CPU simulator support?

Re: What should a CPU simulator support?

[Wenbo Yang]

 > I'm trying to implement a gdb stub for a CPU simulator.
 > The CPU simulator interprets each instruction in a big while loop.
 > My question is: Is it enough for my simulator to support a single step
 > run (simulate a single instruction per called) function to the gdb
 > stub?
If your simulator supports "break" or similar instruction, and the GDB 
for your architecture can do software single stepping, I think you can 
realize this function.

Regards,
Wenbo
--
Wenbo Yang

Intern Software Engineer
SimpLight Nanoelectronics Ltd. 6 Zhichun Road, 10th Floor, Beijing, China
Phone: +86-10-5126-6989   ---  Email: wenbo.yang@simplnano.com

Re: What should a CPU simulator support?

[Jim Blandy]

Wenbo Yang <wenbo.yang@simplnano.com> writes:
>> I'm trying to implement a gdb stub for a CPU simulator.
>> The CPU simulator interprets each instruction in a big while loop.
>> My question is: Is it enough for my simulator to support a single step
>> run (simulate a single instruction per called) function to the gdb
>> stub?
> If your simulator supports "break" or similar instruction, and the GDB
> for your architecture can do software single stepping, I think you can
> realize this function.

(I didn't see the original post, so I'm not sure I have the full
context.)

You really shouldn't need to mess with software single-stepping when
using a simulator.  It's a big distraction, and given the structure of
your simulator, it should be easy to provide what GDB wants directly.

The functions GDB requires are listed in 'include/gdb/remote-sim.h';
none of those should be hard to implement in a simulator; the 'sim'
directory contains many examples of how to hook things up.  You should
consider using the 'sim/common' code if you can, but if not, look at
'sim/m32c' for a very simple-minded approach.  gdb-if.c implements the
remote-sim.h functions in terms of the rest of the sim, which was
originally written as a stand-alone simulator.

Re: What should a CPU simulator support?

[Jim Blandy]

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.

RE: What should a CPU simulator support?

[Robert Norton]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Jim Blandy
> Sent: 05 July 2007 22:32
> To: s88
> Cc: Wenbo Yang; gdb@sourceware.org
> Subject: Re: What should a CPU simulator support?
> <snip>
> 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.

Is this still the recommended way of making a built-in simulator? I
noticed when upgrading our port that the api for simulator implemented
breakpoints has been removed! We're not interested in implementing soft
breakpoints so I had to resurrect this support in remote-sim.c.

Cheers,

Robert

Re: What should a CPU simulator support?

[Daniel Jacobowitz]

On Fri, Jul 06, 2007 at 03:26:48AM -0700, Robert Norton wrote:
> Is this still the recommended way of making a built-in simulator? I

Depends what you mean.  I suppose it is, but I recommend not making a
built-in simulator at all (using TCP to talk to your simulator).

> noticed when upgrading our port that the api for simulator implemented
> breakpoints has been removed! We're not interested in implementing soft
> breakpoints so I had to resurrect this support in remote-sim.c.

Do you mean SIM_HAS_BREAKPOINT?  I believe it was removed four years
ago for lack of any simulators in the tree which used it.  That's life
with an uncontributed port :-)

-- 
Daniel Jacobowitz
CodeSourcery

RE: What should a CPU simulator support?

[Robert Norton]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: 06 July 2007 13:02
> To: Robert Norton
> Cc: Jim Blandy; s88; Wenbo Yang; gdb@sourceware.org
> Subject: Re: What should a CPU simulator support?
> 
> On Fri, Jul 06, 2007 at 03:26:48AM -0700, Robert Norton wrote:
> > Is this still the recommended way of making a built-in simulator? I
> 
> Depends what you mean.  I suppose it is, but I recommend not making a
> built-in simulator at all (using TCP to talk to your simulator).

OK. That's interesting. We support this too but I've always thought it a
little cumbersome compared to built in simulator. Your stdin / out
comment was interesting: I may look into this.
 
> > noticed when upgrading our port that the api for simulator 
> implemented
> > breakpoints has been removed! We're not interested in 
> implementing soft
> > breakpoints so I had to resurrect this support in remote-sim.c.
> 
> Do you mean SIM_HAS_BREAKPOINT?  I believe it was removed four years
> ago for lack of any simulators in the tree which used it.  That's life
> with an uncontributed port :-)

Yeah that's pretty much what I figured. It'd be great if we could
contribute, but unfortunately it's not my decision. All I can do is give
bug reports and trivial fixes. I really appreciate your support though.

Robert

Re: What should a CPU simulator support?

[Daniel Jacobowitz]

On Fri, Jul 06, 2007 at 05:10:19AM -0700, Robert Norton wrote:
> OK. That's interesting. We support this too but I've always thought it a
> little cumbersome compared to built in simulator. Your stdin / out
> comment was interesting: I may look into this.

(Jim's comment actually.)  Yes, we find this very useful at
CodeSourcery; it's still a little cumbersome if you have no way to
give your users either an IDE or some automatic user-defined commands,
but if you can do either of those it's pretty much the same as typing
"target sim" from their perspective.

> Yeah that's pretty much what I figured. It'd be great if we could
> contribute, but unfortunately it's not my decision. All I can do is give
> bug reports and trivial fixes. I really appreciate your support though.

Right.  So, the summary here is that I recommend using the remote
protocol because it provides excellent long-term insulation from the
internals of GDB.  We try not to make backwards-incompatible changes
to the protocol, at least not without discussion and special
circumstances (e.g. no signs that anyone has used a feature in a
decade).  So there's no risk of the Z0 / Z1 packets disappearing,
unlike in the remote simulator.

-- 
Daniel Jacobowitz
CodeSourcery

RE: What should a CPU simulator support?

[Eric Weddington]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: Friday, July 06, 2007 6:20 AM
> To: Robert Norton
> Cc: Jim Blandy; s88; Wenbo Yang; gdb@sourceware.org
> Subject: Re: What should a CPU simulator support?
>
> Right.  So, the summary here is that I recommend using the remote
> protocol because it provides excellent long-term insulation from the
> internals of GDB.  We try not to make backwards-incompatible changes
> to the protocol, at least not without discussion and special
> circumstances (e.g. no signs that anyone has used a feature in a
> decade).  So there's no risk of the Z0 / Z1 packets disappearing,
> unlike in the remote simulator.

Sorry to be dense, but I just wanted to make sure that I understand what
you're saying in how it relates to our situation.

For the AVR target, there is no internal simulator in GDB, but there is an
external simulator available, simulavr:
<https://savannah.nongnu.org/projects/simulavr>
which uses the GDB remote protocol.

You specifically recommend that we keep this layout (external simultor),
rather than try to develop a new AVR simulator that would go into the GDB
tree, correct?

Thanks,
Eric Weddington

Re: What should a CPU simulator support?

['Daniel Jacobowitz']

On Fri, Jul 06, 2007 at 03:53:10PM -0600, Eric Weddington wrote:
> For the AVR target, there is no internal simulator in GDB, but there is an
> external simulator available, simulavr:
> <https://savannah.nongnu.org/projects/simulavr>
> which uses the GDB remote protocol.
> 
> You specifically recommend that we keep this layout (external simultor),
> rather than try to develop a new AVR simulator that would go into the GDB
> tree, correct?

Yes, I do.  That doesn't mean GDB can't change to work better with
your simulator, of course - or that using a built-in simulator is
somehow wrong.  But I've found that a strict partition between a
cooperating simulator and a cooperating GDB has the best results.

-- 
Daniel Jacobowitz
CodeSourcery

Re: What should a CPU simulator support?

[s88]

Hi all:
      I'm trying to implement a gdb stub for a CPU simulator.
The CPU simulator interprets each instruction in a big while loop.
My question is: Is it enough for my simulator to support a single step
run (simulate a single instruction per called) function to the gdb
stub?

thanx

Dave.
-- 
System  on Chip Design  Lab.
Dept. of Computer Science and Information Engineering,
National Chung Cheng University
E-mail : s88.tw@acm.org