[PATCH] sim: testsuite: push $arch out to targets

[Tom Tromey]

Mike> it is kind of nice that you can connect/use the sim today with only gdb
Mike> and not have to juggle another program (especially its lifecycle).

We could keep "target sim" around as a simple wrapper for "target
remote", and it could launch the sim for you.

It's not quite as ideal as having the sim linked in -- the external sim
could be misinstalled somehow -- but it seems like it would be good
enough.

>> This would support my long-term goal of making gdb always target-async.
>> Not all the targets are async-ready, but remote-sim is one that really
>> cannot be made async at all...

Mike> couldn't it create the sim in a thread ?  the sim should be maintaining
Mike> all its own state by itself and not go smashing global state.  or fork
Mike> it as a background process and have gdb maintain a control pipe.

I think the control pipe basically winds up as gdbserver.  It would need
some subset of the existing gdbserver commands -- fetch/store
registers/memory, breakpoints, etc.  It seems better not to invent
another way to do this.

A secondary goal for me is for all the targets in gdb to be
multi-target-capable.  If a sim needs globals, then that wouldn't work.

If the sims are well-behaved about global state, then yes, threads would
be ok.  It was my impression, though, that they are not.  Is that true?

>> One problem with this idea is that the sim can renumber registers.
>> So I guess the sims would have to send over an XML register description.
>> Maybe there are gotchas here, I'm not sure.

Mike> i'm not sure what you mean by the sim renumbering registers.

I stumbled across this in gdbarch.sh:

  # MAP a GDB RAW register number onto a simulator register number.  See
  # also include/...-sim.h.
  m;int;register_sim_regno;int reg_nr;reg_nr;;legacy_register_sim_regno;;0

This seems to be implemented by a number of architectures, though some
of them seem to be unnecessary and/or copy-paste.

I didn't really know how to tackle this and after poking at it a bit I
got discouraged.  I guess figuring out the XML stuff and hacking up the
sim seemed like too much for a random side project.

Also I don't really know how to run even the simplest thing in the sim.
Is there a simple way to get started?

>> Another problem is that this would lose CLI completion for sim commands.
>> However I suppose we could add a remote protocol request for this if we
>> really cared.

Mike> i'm not familiar with the full range of the remote protocol.  ignoring
Mike> command completion, how would it even send custom commands ?  i flipped
Mike> through the manual but nothing caught my eye.

The gdb "monitor" command sends a string to the remote for
interpretation.  I guess in this approach we could make the "sim"
command an alias for "monitor".

I see a few benefits from all this, including the multi-build stuff you
are working on.  We sometimes break remote-sim.c, because right now you
have to specially request it for a particular target.  If remote-sim
were not linked to the sim itself, this would never be a problem.  And,
if the sim handled --enable-target=all, maintainers could simply build
it all the time.

thanks,
Tom