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

[Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>]

On 23 Jan 2021 10:33, Tom Tromey wrote:
> 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.

that would be a nice concession as it'd maintain UX

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

completely fair

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

you mean gdb has more than one target active at a time ?  or that gdb
has the capability to support more than one architecture in a single
build, but only ever has one active target ?

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

my goal has been to move everything into the SIM_DESC structure.  the
common/ code is pretty good in this regard.  it's not 100%, but i think
it's like 95% of the way there, and wouldn't be terribly difficult to
finish it up.

arch ports are all of the place.  some are much better than others.
usually you can get a sense of how good it is by how much of the common
code it utilizes.

so i would say they would all work fine today if you only had one sim
active, and the work to make the sim support multi-targets would have
the side-effect of being thread safe (e.g. support multiple simultaneous
active sims in a single process).

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

oof, i had missed that in my travels.  i'm fairly Blackfin-focused and we
never did anything like that.  that explains some weirdness i'd noticed
though with some ports and their register definitions that i couldn't
explain.

since gdb<->sim are statically linked together, and only ever in a single
build, i'd be inclined to take a one-time hit and break this ABI if only
for the sake of simplifying the gdb side of the world.  it would affect
anyone linking -lsim into their own projects and using the API, but tbh,
i think that's a pretty small userbase, if one exists at all.  we don't
install any headers for it (even though we have some), so people have to
be very dedicated to pull it off.

this would be predicated on the gdb reg nums never changing since their
internal enum values would be coupled with the sim side.  do you think
that's reasonable ?  it's because those internal gdb reg nums are *not*
currently exported is why we have this whole sim reg num remapping ...

my concerns about going all-in on the gdb target description format:
* GDB itself makes XML optional, and i don't think the remote protocol
  supports any other serialized format than XML, so now sim-integration
  would require GDB have XML enabled
* not all of the sim ports that have gdb ports support the format, so
  someone would have to define that core logic first, and i'm certainly
  not an expert in most of these arches to feel confident in doing that.
  i.e. gdb/features/ is missing at least avr, bfin, bpf, cris, frv, ft32,
  and more.

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

the biggest pet peeve of mine is that the gdb/sim has always required you
to load something into it (i.e. an ELF) before you can start to experiment,
and even then, you really need to have it start executing.  if you try to
do anything before that, it just complains nothing is available.

so i hand create a small ELF using gas+ld first (should work everywhere):
$ printf ".global _start\n_start:\n.byte 0\n" > test.s
$ ./gas/as-new test.s -o test.o && ./ld/ld-new test.o -o test

then you can utilize the sim:
$ ./gdb/gdb -q ./test
Reading symbols from ./test...
(No debugging symbols found in ./test)
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .text, size 0x4 lma 0x0
Start address 0x0
Transfer rate: 32 bits in <1 sec.
(gdb) b *0
Breakpoint 1 at 0x0
(gdb) r
Starting program: .../test

0x00000000 in start ()
(gdb) 

now you should be able to explore the sim (regs/mem/etc...).

i'm not sure how much of this behavior is due to gdb and how much is due
to the sim.  i assume it's mostly the sim as you can connect to a remote
target and then immediately start exploring the runtime.

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

ah right, i used to use that when i maintained a gdb stub on top of a usb
jtag device.  that should work fine.

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

i've put together an example sim that works on all targets for people to
use when writing a new port.  maybe that would help here too in the mean
time ?
https://sourceware.org/pipermail/gdb-patches/2021-January/175204.html
-mike