Thanks for the suggestions.
On my Mac, I ran the following:
$ sudo lsof -i -P | grep LISTEN | grep :8864
vmware-vm 1031 root 58u IPv6 0xa4c2462e5f132953 0t0 TCP localhost:8864 (LISTEN)
vmware-vm 1031 root 62u IPv4 0xa4c2464184589c03 0t0 TCP localhost:8864 (LISTEN)
so indeed, Fusion is listening on localhost:8864 on my Mac. Both of these entries correspond to VM-1 which has the debugStub enabled. To confirm, if I shut this VM down, lsof doesn't report anything.
I've tried various combinations of:
debugStub.listen.guest64 = "TRUE"
debugStub.listen.guest64.remote = "TRUE"
with various combinations of "target remote ..." and still nothing.
My Mac IP address is 192.168.0.3 so I even tried "target remote 192.168.0.3:8864" but that doesn't work either.
There is no gdb version for Apple Silicon so running from another VM is my only choice.
Having said that, I noticed that lldb is there so I gave that a go. It gets "so far" as you can see below. I don't have symbols on my Mac for this Linux kernel (yet) and I don't know lldb so will have to play. But hitting 'c' to continue and then 'q' to quit lldb results in the VM being shutdown. Not very useful!
I'd really like to find a solution for gdb from the other Linux VM.
$ lldb
(lldb) gdb-remote 8864
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0xffffffe009248b9c
error: memory read failed for 0xffffffe009248a00
Target 0: (No executable module.) stopped.
(lldb)
error: Process 1 is currently being debugged, kill the process before connecting.
(lldb) bt
* thread #1, stop reason = signal SIGTRAP
* frame #0: 0xffffffe009248b9c
frame #1: 0xffffffe00925a12c
frame #2: 0xffffffe00812e8ec
frame #3: 0xffffffe00812ebd4
frame #4: 0xffffffe0092493a8
frame #5: 0xffffffe009aa1208
frame #6: 0xffffffe009aa1c8c
frame #7: 0xffffffe009aa03e0
