stevepate's Posts

Obviously not a lot of people are running gdb/kgdb on the Linux kernel   I solved my problem in UTM by running 2 VMs using x86_64 emulation. It's slow (kernel compilation takes 17 hours compared to 1 hour native) but it does work. It would be nice if this all worked on Fusion.

I've gone back to UTM for now and using gdb fine sans breakpoints. But that does tell me that it's not an issue with VMtools as open-vm-tools is not running in my VMs. I would love to get this fixed in Fusion. It would be great if someone knows how to do this.

Well that's a depressing read but thanks again. I actually got much further with UTM. Installing Ubuntu 22.10 was very easy (but a somewhat different experience to Fusion). Connecting a gdb client VM was easy. I can read source line by line etc etc. But ... no breakpoints. Sigh! I've been having issues with gdb/kgdb for close to 20 years. My old colleague at VERITAS worked on getting patches into the Linux kernel many years ago. Obviously there aren't enough of us using this technology for it to have high enough priority.  I really don't want to have to buy another laptop. I'll keep exploring ...

One more piece of information ... if I try to install vmtools for this VM (Ubuntu 22.10) Fusion tells me that "VMware Tools is not available for this guest". Their website says that they support "Ubuntu Linux 8.04 through 12.04" If I'm using:     debugStub.listen.guest64.remote = "TRUE" then I'm assuming that the gdb stub should be running inside the guest somehow. Otherwise how do they intercept any requests to this IP:port? Perhaps vmtools is a must have?  I have a lot invested in 22.10 (I'm working on a Linux filesystem book and have a kernel-based filesystem for 5.19.7) - perhaps I'm paying the price for not working on older, stable versions  

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