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

[Mike Frysinger]

On 22 Jan 2021 09:29, Tom Tromey wrote:
> One thing that I think would be nice is if we removed remote-sim.c and
> instead had the sim act as a gdbserver.  This could be done either by
> reusing gdbserver (writing a new sim-based back end)

it's an interesting idea i hadn't thought of before.  i think it could be
bolted into gdbserver in parallel with its existing "low" concept so that
things don't get too messy with the existing host/target logic that it
uses.

it is kind of nice that you can connect/use the sim today with only gdb
and not have to juggle another program (especially its lifecycle).  tbh,
i've never found gdbserver to be super user friendly, and i think having
supported customers trying to use it, many would agree.  though to be
fair, i don't think the current gdb sim cli is super friendly either ...
it's just robust in creating/killing/restarting.

> or by reusing one of the tiny gdbserver stubs from gdb/stubs/.

i looked at the existing gdb/stubs/ and i don't think any of them would
really be useful.  if we can't use gdbserver, then we'd prob implement
our own in the run program itself.

> 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...

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

> 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.

i'm not sure what you mean by the sim renumbering registers.  there are
headers in include/gdb/sim-* for exporting the register numbers that the
sim uses, and they're pretty much frozen from the start of the sim port.
in many cases, the regnum series is exactly the same as gdb's own list.
for example, sim-bfin.h:sim_bfin_regnum & bfin-tdep.h:gdb_regnum are the
same so we don't need two sep codepaths.  but i agree that, if possible,
we should support exporting an XML register description to avoid having
to maintain hardcoded list on either side of the world.

> 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.

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