I always used GDB to do kernel debug. Normally I would run the target kernel inside a VM and run GDB from the host machine. Currently I am working on a project where I need to use XEN hypervisor and I am in a situation where I feel the need to debug a DOM-U from DOM-0. After some searching I couldn't find a way to use GDB in this scenario. Is it possible to use GDB to debug a guest VM running in XEN? If not, what other alternatives I could use?
You can create a pipe (for example, /tmp/mydebug.pipe), then have this line in the .conf file for your domU:
serial = 'pipe:/tmp/mydebug.pipe'
Then you can simply use a tool such as WinDBG from another domU. See mkfifo.
Other possibly useful links:
https://xenserver.org/partners/developing-products-for-xenserver/18-sdk-development/135-xs-dev-windbg.html
http://www-archive.xenproject.org/files/xensummit_intel09/xen-debugging.pdf
https://www.slideshare.net/xen_com_mgr/from-printk-to-qemu-xenlinux-kernel-debugging
Related
I have a arm board, I connect it with my linux (host) system via a wire. I insert sd card with vmlinux.uimg in the arm processor and use minicom on host system. Now I want to debug vmlinux on arm board using gdb. What all thing I need to do? I tried using gdbserver on minicom and gdb on host. But I don't know how exactly it work... Where should I copy vmlinux and how should I debug...
Complete answers depend on your Linux version, development and target setup. Here are some research links,
gdb kernel debugging
kgdb, kgdb docbook or formatted docbook
You need to configure your kernel with KGDB support and you can use the console as a link to control KGDB from your development machine. You need copies of the vmlinux object files on the development machine; easy if it is also the build machine. There are script for GDB to access handy information in the kernel. This is the info in the GDB kernel debugging link.
You do not use gdbserver; this is for user space linux processes. The tool for debugging the kernel is kgdb and this requires code to be put into the kernel. Normally the program gdbserver is using kernel facilities to control a process. This won't work for the kernel itself.
It is possible that not all serial ports will support kgdb. Some versions of Linux allowed kgdb over the network. However, it is not present in as many kernels as the serial port. You can activate kgdb over serial with a kernel parameter kdbgoc, sysfs or magic sysreq. Some devices (and Linux versions) may have support for JTAG type kgdb.
Now a days debugging become so advanced that even 'core kernel source code' can be debugged using Virtual environment.
But after reading couple of blog related to Kernel Core development it was not clear whether they are debugging using Virtual environment.
They have mentioned that they rely on 'Printing message' rather than using debugging tool, at-least for core component.
So, I Request from 'Linux Kernel Experts' to let me know what is good practice followed while debugging Kernel?
I've tried multiple approaches when trying to debug the kernel.
Sometimes, the easiest way is to just add a few printk statements based on my own conditional values, monitor the serial log and see what's going on. Its especially useful when the function in question is invoked quite often, but you are interested only in a subset of those.
QEMU GDB debugging. I have a buildroot filesystem setup. This means the kernel is lean and it boots up real fast. I start qemu with the -s -S flags, and attach gdb as target remote :1234. Additionally, there aren't very many userspace processes in this setup so its easier to debug the kernel.
VMWare stub. Assuming you are running an Ubuntu VM, it is possible that you can attach gdb to a VMware stub and debug the kernel. Personally, I never have had to pursue this route, but I look forward to trying it out someday.
If you have a kernel for a device that gets stuck in a bootloop and it does not print out any debug information out onto serial, it still might be helpful to try and boot it up using QEMU. Sure, the booting up will probably fail as the kernel tries to load up drivers, but you should be able to attach gdb, get a stack trace and see what the root cause is(perhaps a recursive call).
I am using Ubuntu 13.10. Is it possible to debug a windows executable under Linux?
I've tried gdb, but it always throw me this error message.
/bin/bash: line 0: exec: /some.exe: cannot execute: Permission denied
I don't have much experience with this but, I think, what you're looking for is winedbg. Initially, it should allow you to debug Win32 applications in Linux.
I suggest you try the IDA Debugger (cross platform debugger).Hope it helps.
You are trying to execute a program designed to run in a OS, from within another one, which could be using a complete different processor than a x86.
In order for a executable program to be run in a specific OS, these modules or services must exist:
A module that can understand the binary code of the executable program and translate, if needed, into binary code of the host processor.
A service that can intercept any instruction identified as a system call, and emulate its behaviour using host resources
A module that is able to load, parse and prepare a process block to acommodate the new "guest" process
This is just for executing a program. To debug it, you also need a service that can interact with the above mentioned modules/services in order to control execution of that program.
That said, you can probably debug an EXE file using some utility from the Wine project, asumming your Ubuntu is running on a x86 processor. Take a look at it.
http://www.winehq.org/
Also, I recall VirtualBox offers some sort of debugging help for processes running on the guest OS, but I'm not sure about this.
No, it is NOT possible to debug a Windows executable under Linux.
I'm trying to debug an application for an ARM processor from my x86 box. I some followed instructions from someone that came before on getting a development environment setup. I've got a version of gdbserver that has been cross-compiled for the ARM processor and appears to allow me to connect to it via my ARM-aware gdb on my box.
I'm expecting that when the process I've got gdb attached to crashes (from a SIGSEGV or similar) it will break so that I can check out the call stack.
Is that a poor assumption? I'm new to the ARM world and cross-compiling things, is there possibly a good resource to get started on this stuff that I'm missing?
It depends on the target system (the one which uses an ARM processor). Some embedded systems detect invalid memory accesses (e.g. dereferencing NULL) but react with unconditional, uncatchable system termination (I have done development on such a system). What kind of OS is the target system running ?
So i assume that the gdb client is able to connect to gdbserver and you are able to put the break point on the running process right?
If all the above steps are successful then you should put the break point before the instruction which crashes, lets say if you dont know where is it crashing then i would say once the application is crashed, the core will be generated, take that core from the board. Then compile the source code again with debug option using -g option(if binaries are stripped) and do the offline ananlysis of core. something like below
gdb binary-name core_file
Then once you get gdb prompt ,give below commands
gdb thread apply all bt
The above command will give you the complete backtrace of all the threads, remember that binaries should not be stripped and the proper path of all the source code and shared lib should be available.
you can switch between threads using below command on gdb prompt
gdb thread thread_number
If the core file is not getting generated on the board then try below command on board before executing the application
ulimit -c unlimited
I know it is possible to remotely debug code using gdb's server mode and I know it is possible to debug code that has been cross-compiled for another architecture, but is it possible to go a step further and remotely debug Linux applications from OS X using gdbserver?
Certainly, but you need a cross-compiled GDB, compiled for OSX-host and Linux-target. This is not at all uncommon; there should be plenty of GDB documentation to cover this.
It is possible from Windows with Cygwin.
I don't know about OS X.