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

Tom Tromey
2021-01-23T17:33:13Z

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