I learn to use lldb to debug mac IOKit drivers in macOS 10.12.3.
two machine debug.
It's easy to connect to target machine when panic occurs.
I wonder how to show target machine system message?
Is there any command like "dmesg" in lldb?
You can connect the target and debugger machine using a FireWire cable. Set the 0x08 bit in the target machine's debug= kernel argument (DB_KPRT), and anything logged with kprintf (note: not printf/IOLog) will be routed to FireWire. (Firewire is used unless the Mac has a Serial port, which modern Macs do not - virtual machines can, though.)
To view this output, you need to be running the fwkpfv command on the Mac on the other end of the Firewire cable.
This method works fine with Thunderbolt-to-Firewire adapters and docks too, although I suspect not if you hotplug them.
Related
I'm trying to kernel debug a physical Macbook pro device.
When my setup contains a VM, between a host MacOS and guest MacOS, its working with no problem using lldb -o "kdp-remote <guest_machine_ip>"
my boot-args on my remote (to debug) Macbook are:
user$ nvram boot-args
boot-args debug=0x44 kext-dev-mode=1 pmuflags=1 -v kcsuffix=debug
When i'm triggering kernel debug using either
sudo dtrace -w -n "BEGIN { breakpoint(); }"
or LEFT CMD + RIGHT CMD + PowerButton, the system is in halt mode, not responsive to anything (Mouse not moving, etc)
But when I'm trying to connect to the machine from the host using the lldb command provided earlier, it's not working.
I've made sure the machines can ping each other and I can set up a SSH connection.
To the best of my understanding, I had to user special Apple adapters (Real™ Ethernet adapter), so I'm using the following adapters to debug the remote machine:
https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter
https://www.apple.com/shop/product/MD463LL/A/thunderbolt-to-gigabit-ethernet-adapter
The physical connections setup looks like that:
MacOS-Debugger --(USBC to Ethernet adapter)--> Ethernet cable <-- (ThunderBolt to Ethernet adapter) <-- (ThunderBolt3 to ThunderBolt2 adapter) <-- MacOS-debuggee
Generally for the debugging I used the following tutorial, which worked for VM debugging:
https://knight.sc/debugging/2018/08/15/macos-kernel-debugging.html, I didn't find the exact KDK version, but I don't think it should be the problem here
My debugger is BigSur, and my debugee is Catalina
Any ideas to what the problem may be will be helpful
Your hardware setup sounds fine. Note that you don't necessarily need a direct ethernet cable connection, you can use your normal office-/home-wide wired network, it's fine to have a switch (or even more than one) between debugger and target. The debugger machine can even be using wifi as long as it can reach the target's wired network connection that way, though it's not recommended. The Thunderbolt Ethernet interface need not be Apple branded, but its driver does need to include kernel debugging support. In practice, for example, I've successfully used the Ethernet port in a OWC brand Thunderbolt Dock as well. Using one of Apple's own adapters of course guarantees it will work.
If the boot-args on your target machine are the same as what you used in the VM, that's probably where your problem is coming from. You should specify the device to be used for kernel debugging, using the kdp_match_name= option. Use the ifconfig command in the Terminal to work out which of the listed devices is your Thunderbolt ethernet adapter (enX), possibly based on the IP address. en0 is typically wifi in Mac laptops, so you're usually looking for X > 0.
So you'll end up with something like kdp_match_name=en1 added to your boot-args. Make sure to reboot the machine cleanly before attempting a debugging session after updating the boot-args setting.
A few more comments:
kext-dev-mode=1
This option no longer has any effect. It only existed in OS X 10.10. You can remove it.
I didn't find the exact KDK version, but I don't think it should be the problem here
Having a KDK version that doesn't match the target's exact kernel binary UUID will not prevent a connection, but it will prevent you from doing any meaningful debugging as the memory layout of threads etc. will not be available.
My debugger is Big Sur, and my debuggee is Catalina
If you ever run Big Sur on your target, make sure to add wdt=-1 to your boot-args or the hung/crashed machine will reboot before you get a chance to connect with the debugger.
I'm working on STM32H7 evaluation boards (Nucleo-144 and EVAL2). My IDE is STM32CUbeIDE.
My goal is to debug remotely: run STM32CubeIDE (or another IDE) on a Linux server and connect to the board through the network.
I could run successfully the following setup:
connect the board to a local PC
launch GDBserver on this local PC
on the distant Linux server, setup the Debug Configuration to connect to the remote GDB server.
This is working fine. But I need to go further: I'd like to remove the local PC, ie. the board would be connected directly through ethernet to the network.
I've been told that there is a JTAG/Ethernet adapter for Xilinx, called Smartlynq that allows to do that, but the way it works is a bit confusing for me.
Do you know about an equivalent for STM32 ecosystem ?
Would there be another setup to debug remotely without a PC in between ?
The Segger J-Link PRO is a JTAG/SWD debugger for ARM that supports Ethernet. Like the other J-Link models, it should work fine for STM32.
Use a Raspberry PI as a debug adapter.
It would be somewhat cheaper than a JLINK Pro. If there is WLAN available, take a Pi Zero W, otherwise you'd need one of the bigger ones with Ethernet. Set it up for remote work (enable ssh, set a fixed IP address etc), then you can disable the GUI desktop, and disconnect the display and the keyboard.
Running gdbserver
The Pi has an ARM CPU which supports the Thumb instruction set but not Thumb-2, so its native gdbserver might be able to debug a Cortex-M7 controller. If it can't, then you have to install the gdb-arm-none-eabi package on the Pi.
Connectint to the target board
There are two alternatives.
Connect the onboard debug adapter to an USB port on the PI, and run openocd just the way you do it on a PC.
Bypass the onboard debug adapter, and connect some pins on the Pi directly to the SWD pins of the target. You have to remove some jumpers to disable the onboard debug adapters. There is a tutorial at Adafruit on how to compile and use openocd with native SWD support.
I have to use firewire as my kernel extension loads before the target has an IP address.
My kernel extension calls PE_enter_debugger() in its start routine.
I see "waiting for debugger" twice, then just once the console says
"kdp_poll: no debugger device".
I would think that means the nvram boot-args is wrong but I've
followed the instructions:
debug=0x814e kcsuffix=development kdp_match_name=firewire fwkdp=0x8000
The host is a late 2012 Mac Mini, macOS 10.12.4 build 16E195.
The target is a mid 2010 Mac Pro with the same macOS build.
My kernel debug kit matches the macOS build.
Google yields no joy. Have you a clue for me?
The 2010 Mac Pro has built-in Firewire ports and no Thunderbolt, so I think your problem might be the fwkdp=0x8000 setting. As far as I'm aware, you only want to set that if you're debugging through a Thunderbolt-Firewire adapter (or Thunderbolt display's or dock's Firewire port) on the target machine side.
(Sorry, only just seen your question as I have alerts on the 'xnu' and 'kext' tags but 'kernel' and 'osx' are too noisy.)
I have a Mac running VirtualBox with a Win 8.1 client VM.
I have a program to run in the VM that requires access to a USB dongle — note, not a storage device! Sadly, whenever the Mac restarts it grabs the dongle, so before the VM can use it remote hands must physically remove it from the Mac and plug it in again.
Is there some way to programmatically eject (virtually, not physically of course) such a USB device from the Mac so that the VM can then take over ownership? I'll be happy to dig into I/O Kit or whatever Framework in Cocoa may be needed to accomplish this. I'd just rather not start if it's obviously impossible.
This question and answer is similar to what I'm looking for, but Step 6 is "Remove the USB device from your physical machine." I'm trying to avoid fiddling with the physical hardware by hand so that I can automate the process.
I'm finding it difficult to see the debug output from a kernel-mode driver I'm working on.
I'm new to driver development. I'm trying to debug a USB driver on Windows XP. I've installed the DDK, and built a "checked mode" build of my driver. I've installed the driver and if I use a hex editor to look at my driver's .sys file in windows/drivers, I can see the text of my debug output strings.
If I run an app that uses my driver under Visual Studio, my debug output doesn't appear in the output window, as the application's own debug output does. Searching the web, I find many different claims about how one is supposed to display debug output from the kernel. For kernel debugging in general, people seem to either do remote debugging over a NULL modem cable (Crikey, it's 2012) or use a virtual machine and a virtual com port. Both these approaches seem like a massive amount of work just to be able to see debug output. Is there an alternative?
I've tried using WinDbg in "Local" kernel debugging mode but it doesn't show anything. It warned that I should reboot windows with "/debug" enabled. I did that, but it didn't help.
Any other ideas? Or am I asking for the impossible?
DebugView will show you the trace messages from your driver:
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
However, you really do need a two machine setup to do any real development work.
The information you found is correct. You do need 2 machines to debug kernel-mode drivers.
If you choose to use 2 physical machines they can be connected via USB. NULL modem (COM port) is a common way to attach debugger to a virtual machine where VM's COM port is seen as a named pipe on the host, so you don't really need a NULL modem cable.
Couple of links
http://msdn.microsoft.com/en-us/library/ff538141.aspx
http://msdn.microsoft.com/en-us/library/ff542279.aspx