i am using ubuntu 12.04 and kernel version is 3.12.6, i want to learn how to use kgdb to debug kernel. I didn't get much info. regarding kgdboe (kgdb over ethernet). I have compiled kernel and enabled kgdb in menuconfig, i have created kernel image using make bzImage on development machine and copied same on target machine, now problem is how to connect both target and development machine. i m not getting parameter set for kgbdoe. Plz help if anybody know how to use kgdb over ethernet
Have you read this:
https://www.kernel.org/pub/linux/kernel/people/jwessel/kgdb/ch03s04.html
?
You have to run debugged kernel with special options - like for example:
kgdbwait kgdbcon kgdboe=#192.168.248.76/,#192.168.242.24/00:11:22:33:44:55
and on debugging side you run following commands:
gdb
file vmlinux
target remote udp:192.168.248.76:6443
it has worked for me.
You can get the kgdboe source from here, build it and load it into your kernel:
make -C /lib/modules/$(uname -r)/build M=$(pwd)
sudo insmod kgdboe.ko
Then type 'dmesg' to see the load log and get instructions on connecting from gdb.
Related
I download Linux kernel source code, successfully compiled it and run it with BusyBox in QEMU.
Because of BusyBox, I can use some frequently-used tools, such as vi,ls,cp,cat, etc.
But when I try to compile a simple "hello world" C/C++ program, I get gcc: not found.
In addition, I can't make a new Linux module by make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules inside QEMU.
I googled a lot, still can't figure it out.
So my question is: how can I install common developer tools like gcc, make, etc. inside my bare-bones QEMU VM that is running my custom Linux kernel (and not a standard distribution)?
I see that you are trying to compile some program (or module) to use it inside your QEMU machine, but you do not have a compiler toolchain installed in the machine itself. You have a couple of options:
Probably the easiest: since you already compiled the kernel that you are using for QEMU externally (in your host machine), you can easily also compile anything else this way. For modules, just pointing make to the same kernel source directory where you built the VM kernel should suffice. Once compiled you can then copy them inside the VM disk/image like you did for busybox.
You can download and compile your own GCC from source (always on the host), and then install it inside the QEMU virtual machine. This is usually done by mounting the VM disk (QEMU image or whatever you are using) somewhere (e.g. /mnt/my-qemu-disk) and then configuring GCC with --prefix=/mnt/my-qemu-disk/usr/local, building and installing it with make install. This and other stuff is explained in this documentation page.
Once you have GCC installed inside the machine, you should be able to use it as you normally do. You can now use it to compile GNU Make inside the VM, or you can just compile outside in the same way.
For complex stuff like building kernel modules you will probably also need to build and install GNU binutils in the machine, again either from the inside with the GCC you just installed or from the outside.
I have cross compiled a simple helloworld kernel module, the host is a x86 machine and the target an ARM board. When I do modprobe to install the module in the target i get this message:
FATAL: Could not load /lib/modules/3.14.0-xilinx-13567-g906a2c9-dirty/modules.dep: No such file or directory
I have make sure that the module is compiled with the same version as the target.
uname -a : 3.14.0-xilinx-13567-g906a2c9-dirty
modinfo: vermagic: 3.14.0-xilinx-13567-g906a2c9-dirty SMP preempt mod_unload modversions ARMv7 p2v8
What can be the problem? What does that error means?
Apparently, you are missing the file specifying module dependencies (generated at build time and installed with make module_install).
The simplest solution is, if your mdule does not have external dependencies, insert it with insmod rather than with modprobe.
Try to run:
depmod -a
on the ARM board.
it should solve your problem.
I would suggest the following steps.
Do insmod $module-name
Check the dmesg commands output. If you see the following message
version magic '3.14.0-xilinx-13567-g906a2c9-dirty xxxxxxxx' should be
'3.14.0-xilinx-13567-g906a2c9-dirty xxxxxxxxxx'
then the problem is because of the changes made to the kernel.
Commit the changes to the git repository and re-build the kernel.
Create a new kernel image and then boot the target with the updated kernel.
I am working on academic project that modifies some Kernel Networking code as well as include a new Kernel module.
I am using QEMU to load modified kernel and test.
However, i find that a complete OS is required in some .img to debug.
Is it possible without it ?
Or, which is the distro that can be used with Kernel 2.6 for system. The distro need not have any features, except ability to run programs, including networking support.
The easiest way in my opinion is to use buildroot
http://buildroot.uclibc.org/
clone it, configure it to use your custom kernel (default userspace is fine for a start, you might want to change it later).
it will build your kernel and root filesystem. the entire process takes about half an hour, twenty minutes of which is compiling the monster
my run line looks something:
qemu-system-i386
-hda rootfs.ext2
-kernel bzImage
-m 512M
-append "root=/dev/sda console=ttyS0"
-localtime
-serial stdio
and some more options regarding a tap device
Minimal fully automated QEMU + GDB + Buildroot example
QEMU + GDB on non-module Linux kernel is covered in detail at: How to debug the Linux kernel with GDB and QEMU? and building the kernel modules inside QEMU at: How to add Linux driver as a Buildroot package Get those working first.
Next, I have also fully automated GDB module debugging at: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/1c29163c3919d4168d5d34852d804fd3eeb3ba67#kernel-module-debugging
These are the main steps you have to take:
Compile the kernel module with debug symbols:
ccflags-y += -g -DDEBUG
as mentioned at: kernel module no debugging symbols found
Stop GDB with Ctrl + C and run:
lx-symbols path/to/parent/of/modules/
This amazing command, which is defined in a GDB Python script inside the Linux kernel source tree, automatically loads symbols for loaded modules present under the given directory recursively whenever GDB stops.
The best way to make that command available is to use:
gdb -ex add-auto-load-safe-path /full/path/to/linux/kernel
as explained at: GDB: lx-symbols undefined command
insmod the kernel module.
This must be done before setting breakpoints, because we don't know where the kernel will insert the module in memory beforehand.
lx-symbols automatically takes care of finding the module location (in host filesystem and guest memory!) for us.
Break GDB again with Ctrl + C, set breakpoints, and enjoy.
If were feeling hardcore, you could also drop lx-symbols entirely, and find the module location after insmod with:
cat /proc/modules
and then add the .ko manually with:
add-symbol-file path/to/mymodule.ko 0xfffffffa00000000
I'm trying to cross compile the FTDI VCP Driver for my embedded arch linux arm machine. I downloaded the source files from http://www.ftdichip.com/Drivers/VCP.htm onto my host machine which is running kernel:
2.6.32-54-generic-pae
When running the Makefile, I get errors related to kernel headers, ie: asm/thread_info.h file not found. I realize that this means that my asm symlink is broken, so I tried linking it to
linux-headers-2.6.32-54/include/asm-generic
but the contents of that directory does not include thread_info.h either, which I'm trying to find.
Has anyone cross compiled the FTDI VCP Driver for embedded arch linux arm using Ubuntu as their host and can point me in the right direction? I'm new to building kernel modules and cross compiling and any help would be appreciated.
If anyone requires more information I'd be more than happy to add it.
make ARCH=arm menuconfig
Make and install modules: make modules and make modules_install
Don't forget: insmod usbserial.ko and insmod ftdi_sio.ko if you need to, and depmod -a to have them load after a power cycle.
Don't forget to include your cross compiling chains.
Basically u need cross-compile kernel in host x86 machine.
First check the source code is already configured and built if so.
make ARCH=arm menuconfig
window ll appear and enable ftdi in driver .
if source code is clean.
then u need to copy /proc/config.gz file from target machine to host and untar it.
copy to source top folder like `cp config .config'
make ARCH=arm menuconfig
and enable your driver
After this make ARCH=arm CROSS_COMPILE=<your tool chain> zImage
e.g make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage
make ARCH=arm CROSS_COMPILE=<your tool chain> modules
e.g make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- modules
The FTDI "VCP" driver has been a part of the linux kernel for a good while now. You don't need to download anything, except for the kernel itself. As long as you can cross-compile your kernel, you're all set.
I 've cross compiled a Linux Kernel (for ARM on i686 - using Cross-LFS).
Now I'm trying to boot this Kernel using QEMU.
$ qemu-system-arm -m 128 -kernel /mnt/clfs-dec4/boot/clfskernel-2.6.38.2 --nographic -M versatilepb
Then, it shows this line and waits for infinite time !!
Uncompressing Linux... done, booting the kernel.
So, I want to debug the kernel, so that I can study what exactly is happening.
I'm new to these kernel builds, Can someone please help me to debug my custom built kernel as it is not even showing anything after that statement. Is there any possibility of the kernel being broken? ( I dont think so, b'se it didnot give any error while compiling )
And my aim is to generate a custom build very minimal Linux OS. Any suggestions regarding any tool-chains etc which would be easy & flexible depending on my requirements like drivers etc.,
ThankYou
You can use GDB to debug your kernel with QEMU you can use -s -S options. If you want a simple and reliable toolchain, you can use ELDK from DENX (http://www.denx.de/wiki/DULG/ELDK).
You can install it like this (It's not the last version, but you got the idea):
wget http://ftp.denx.de/pub/eldk/4.2/arm-linux-x86/iso/arm-2008-11-24.iso
sudo mkdir -p /mnt/cdrom (if necessary)
sudo mount -o loop arm-2008-11-24.iso /mnt/cdrom
/mnt/cdrom/install -d $HOME/EMBEDDED_TOOLS/ELDK/
The command above should install the toolchain under $HOLE/EMBEDDED_TOOLS/ELDK (modify it if you need)
echo "export PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin" >> $HOME/.bashrc
You can then see the version of your ARM toolchain like this:
arm-linux-gcc -v
You can test a hello_world.c program like this:
arm-linux-gcc hello_world.c -o hello_world
And you type: file hello_wrold to see the target architecture of the binary, it should be something like this:
hello_wrold: ELF 32-bit LSB executable, ARM, version 1 (SYSV)
Now if you want to compile a production kernel, you need to optimize it (i suggest using busybox) and if you want just one for testing now, try this steps:
Create a script to set your chain tool set_toolchain.sh:
#! /usr/bin/sh
PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin
ARCH=arm
CROSS_COMPILE=arm-linux-gnueabi-
export PATH ARCH CROSS_COMPILE
And run your script (source ./set_toolchain.sh)
Download a linux kernel and unzip it (Let's assume 2.6.x, it's an old kernel, but there are a lot of chances that it work without compilation errors).
Inside your unzipped kernel:
cd ~/linux-2.6.29/arch/arm/configs
make versatile_defconfig
Here we use versatile chip, you may need to use make menuconfig to modify the option OABI and set it to ARM EABI, this option is under Kernel features menu
After all this steps, you can compile you kernel:
make
if you want verbose compilation make v=1
After this you got your kernel under arch/arm/boot/zImage.
Hope this help.
Regards.
I would suggest to build your kernel by activating the option in the section Kernel hacking of your configuration file.
Then you may use kdb or kgdb which is easier to use but requires another machine running gdb.
`
You can also connect Qemu and GDB. Qemu has the -s and -S options that run a GDB server and allow you to connect to it via TCP to localhost:1234. Then you can load your kernel image (the unzipped one) in GDB and see how far your kernel boots.