I am using Qemu to learn some linux kernel development/hacking and wanted to debug the boot process of Linux (2.6.34.3). I have compiled for the ARM versatile platform and is using Codesourcerys arm-none-eabi crosscompiler. I am using Eclipse as the environment to build and debug using gdbserver.
So I have manged to successfully build and run the kernel in qemu but the problem is that I dont see any source code in the debugger at the boot process(at address 0), I can only see the disassembly code. However, when it switches to virtual memory at init/main.c (address over 0xC0000000), the source code appears and I can see the source code and step through and over code. Why is that? I want that from the beginning.
Anyone have any tips on how to debug the boot process of Linux? All the guides in google shows how to debug the kernel, but they all show from start_kernel() (located in init/main.c) and not from the beginning of the boot process (in arch/arm/boot/compressed/head.S). Anyone with experience help please, thank you!
Looked into the System.map in the root folder and there is only symbols for stuff from c0004000 (where the virtual address start). I load vmlinux into gdbserver to get debug information, Maybe thats why theres no source?
The Linux kernel uses a 2-step booting processing (and this does not include any boot loader like u-Boot ...). You can better understand this especially by looking into 2 .lds files (detailed below) for linking:
arch/arm/boot/compressed/vmlinux.lds.in, which generates arch/arm/boot/compressed/vmlinux.lds.
Along with other .o files in arch/arm/boot/compressed, a vmlinux is generated inside this folder.
You can use arm-none-eabi-nm -a -n arch/arm/boot/compressed/vmlinux to see the symbols for this stage. All addresses are physical addresses.
These symbols are NOT included in System.map
The second vmlinux is generated by kernel .o files and arch/arm/kernel/vmlinux.lds (note: the path is different)
I hope this explains why you can not see the booting source code in Eclipse.
linux kernel is too complex to understand(for a beginner).
Why dont use use a smaller OS like xv6:
OS is small, sourcecode is about 8000 lines
used by many universities
based on V6(unix),
boot process is the same except that its less complicated than that of linux.
Appendix B of the xv6 book deals with boot process(its short and sweet).You can run gdb on qemu and see the boot process, the main files to check out for are bootasm.S(in assembler) and bootmain.c.
This is much simpler and easier to do and understand when compared to linux.(atleast for beginners).There are assingmennts on , setting up qemu , using gdb ,tracking the boot process , doing changes to the source code etc in the link given.Give it a shot :)
Cheers,
sharan
head.S is written in assembly, not C. That's what the .S suffix indicates.
Related
I am trying to debug a driver in UEFI firmware (OVMF) via gdb as described here:
https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB
It works well, but I discovered that just having debug symbols for my driver is not enough. I also need debug symbols for the whole OVMF image to properly see what's going on. I have a lot of .debug files after OVMF is built with edk2, but I don't understand which ones I need to load into gdb, and what addresses I should use.
I found some instructions involving DebugPkg, but I couldn't make gdb_uefi.py work no matter what. It always failed to locate EFI_SYSTEM_TABLE_POINTER.
In the end, I ended up writing my own script, which implements gdb command that does manage to successfully load all debug symbols. It is probably a worse solution, since it requires a setup: "debug.log" with driver addresses must be present when loading is performed, so you need to run QEMU at least once first. But, this is good enough for me.
My script can be found here:
https://github.com/artem-nefedov/uefi-gdb
I am trying to write a simple OS, I already wrote a bootloader but now I want to debug it, so I switched from using VirtualBox to QEMU because I saw it had better debugging.
The problem is that after I added the -s parameter to QEMU command and successfully connected via GDB, it says that the symbol table isn't loaded and that I should use the "file" command.
The only difference from what I did to what I saw people on the Internet do, is that they started GDB with gdb vmlinux, but I can't do that because I am not debugging a Linux kernel... so I figured that the issue is that I didn't start GDB with an executable, but using the "file" command on my OS image, and the compiled and linked .out file, tells me it's a "DOS/MBR boot sector", so I can't start GDB with either of them (I tried to do that anyways, but GDB failed).
Help would be appreciated.
EDIT: also, I did assemble the bootloader with the -g and --gstabs+ options.
gdb would like a file so that it can give you symbolic debugging information. For that you will need to give it a file in a format with debug info which corresponds to where your OS ends up in RAM. The "DOS/MBR boot sector" file is a disk image (the BIOS will load part of this into RAM for you, and it will then presumably finish loading code itself).
But gdb will also entirely happily let you do assembly-level debugging; you can just ignore the warning about not having a symbol table, and use the single step instruction, disassemble-from-pc and similar commands:
"disas $pc,+32" disassembles 32 bytes from the current PC
the display command prints after execution stops, so "disp /3i $pc" will print the next 3 instructions every time gdb gets control
"stepi" and "nexti" do single-instruction step/next ("step" and "next" are source-line stepping and require debug info)
I've just compiled BPF examples from kernel tools/testing/selftests/bpf and tried to load as explained in http://cilium.readthedocs.io/en/v0.10/bpf/:
% tc filter add dev enp0s1 ingress bpf \
object-file ./net-next.git/tools/testing/selftests/bpf/sockmap_parse_prog.o \
section sk_skb1 verbose
Program section 'sk_skb1' not found in ELF file!
Error fetching program/map!
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
I suspect I'm running into some toolchain/kernel version/features mismatch.
What am I doing wrong?
I do not know why tc complains. On my setup, with a similar command, the program loads. Still, here are some hints:
I think the problem might come, as you suggest, from some incompatibility between kernel headers version and iproute2, and that some relocation fails to occur, although on a quick investigation I did not find exactly why it refuses to load the section. On my side I'm using clang-3.8, latest iproute2, but also the latest kernel (some commit close to 4.14).
If you manage to load the section somehow, I believe you would still encounter problems when trying to attach the program in the kernel. The feature called “direct packet access” is only present on kernels 4.7 and higher. This is what makes you able to use skb->data and skb->data_end in your programs.
Then as a side note, this program sockmap_parse_prog.c is not meant to be used with tc. It is supposed to be attached directly to a socket (search for SOCKMAP_PARSE_PROG in file test_maps.c in the same directory to see how it is loaded there). Technically this does not prevent one to attach the program as a tc filter, but it will probably not work as expected. In particular, the value returned from the program will probably not have a meaning that tc classifier hook will understand.
So I would advise to try with a recent kernel, and to see if you have more success. Alternatively, try compiling and running the examples that you can find in your own kernel sources. Good luck!
I am bit new to this field and my query here is a bit vague. I am particularly interested in how any of you, who have had experience with uBoot and a JTAG debugger (like a Lauterbach), have gone about tackling and resolving an issue within uBoot.
Specifically, I would really appreciate if you could describe the problem encountered within uBoot, and how did the JTAG help you resolve the issue.
Thanks,
vj
I have used this many times using Texas Instruments' CCS debugger. I would create a dummy project with the u-boot source code and then attach. Afterward, I can load the u-boot symbols or the u-boot app itself and step through the code. Reloading and restarting u-boot is helpful to work through issues.
This applies to any problem with u-boot, including start-up problems.
I use LPCXpresso (based on Eclipse) to debug U-Boot on my board (with LPC4350 MCU).
But be careful, you could have problem to debug and you maybe need to modify the .lds file (linker script).
You have to find this file but be cautious, the file is copied and modified when you configure the compilation for your board, you have to look for the original file.
Then if you find
/DISCARD/ :
{
*(*)
}
in the .lds file, you won't be able to debug. Just remove it or comment it.
A while back I was following some tutorials an assembly. I was running it all on a windows machine, compiling with NASM and then writing the compiled code to a floppy disk, then reboot and try the code. This process was long and time consuming and sadly was not on a mac. When I found out that Xcode for mac installed NASM I immediately tried to compile some code. The code compiled fine. The issue is testing it. On a mac I have no floppy (not like I want to use one) so Im not sure how to test this. I looked in to Q (kju) and found it would only emulate things on an ISO file. So I guess what Im asking is is it possible to install the compiled code on an ISO file for testing? (Note: the code when compiled forms a .bin file)
Thanks for any help
I don't know exactly what you are trying to test (a boot loader maybe?) but you don't need to reboot or boot from a disk just to run assembled code (unless it is a boot loader or something).
Either way, if you need to "reboot" to test, I suggest running an emulator. Sun VirtualBox is super easy to use and free and emulates a standard x86 architecture (including floppy drives)! So that may work for you in the short term. If you ever want to create an ISO image in the future, you can do that with the command line utility hdiutil. In a terminal window, type man hdiutil or visit the online man page for more information on using that to create all kinds of disk images.