I want a debugger to debug my OS. At many places i am not being able to figure out what is wrong. So is there any debugger which can debug operating systems? can i do it with gdb?
You will need to use a solution which emulates another computer on your computer - essentially, a virtual machine. The most obvious ones which come to mind instantly are VirtualBox and VMware, but those weren't designed with debugging the machine and/or the OS.
What you're looking for is either Bochs or QEMU. Both (as far as I remember) can be integrated with gdb in order to set breakpoints and analyze the execution of your code. You might also want to read this OSdev.org article.
I primarily use Bochs for testing my OS projects. It includes a helpful debugger (bochsdbg).
Related
I am just learning linux kernel programming with the LINUX KERNEL DEVELOPMENT book(I am beginner linux kernel programming but not on linux programming). It is possible to test programs in a kernel machine with VMware viritual on Ubuntu without damage my system ?
Yes you can safely test kernel modules on a virtual machine!
I'll give you some links that may help:
watch this site
http://free-electrons.com/
in particular this book:
http://free-electrons.com/doc/books/ldd3.pdf
Also this guide:
http://www.tldp.org/HOWTO/Module-HOWTO/
An embedded distro is even better
An Ubuntu guest is fine, but I prefer to keep things minimal and use an embedded distro, as this will make things:
simpler and easier to understand and control
faster
In particular, I recommend using:
Buildroot, which is highly configurable, documented and maintained, also builds host QEMU so easy to patch it up (e.g. to add your own devices since out-of-tree devices are not possible yet ?)
QEMU emulator: small comprehensible source, ARM support, official Android emulator, kernel GDB support
Embedded distros can generate rootfs images smaller than 10MiB, and it becomes possible to understand the entire userland setup, which will make it easier to focus on the kernel.
I have made a setup to make everything as automated as possible: https://github.com/cirosantilli/linux-kernel-module-cheat
I've been using a VM for a long time for Linux kernel programming and I've never had any problem. Actually, if you manage to violate the protections of a VM then you will probably be hired by Oracle or VMWare :D
However, I recommend you to read this post: https://security.stackexchange.com/questions/23452/is-it-safe-to-use-virtual-machines-when-examining-malware
I have downloaded EDK (UEDK2014) from taniacore site and I have successfully build UEFI application in Debug mode using following command
C:\UDK2014.Complete.MyWorkSpace\UDK2014.MyWorkSpace\MyWorkSpace>
build -t VS2012x86 -b DEBUG
As it is in Debug mode it will create a .pdb file (SecMain.pdb). My Question is How to debug this binary using VS 2010.
I trided doing that by running SecMain.exe, attach it to Visual Studio 2010 and start debugging but not able to do that. Could any one have done this (Debugging an UEFi application using VS 2010) before ? please let me know if you have solution to this.
Yes, you can use an emulator as #sun2sirius said. The only problem though if your UEFI App or driver accesses the hardware directly the emulator won't help. In this case unfortunately "printf" is your best friend. So good Trace/Log library will help you to debug your driver.
There are a few ways to simplify the development:
Write as much platform-independent code as you can. Easier to debug in VS IDE under the Windows. Windows has protected memory pages and debugger will catch all potential memory issues; UEFI is in real mode, so your platform dependent code is not protected against accessing dunging pointers, buffer overrun etc. So again Trace/Log library is a big help.
There is a hardware debugger on the market like Arium. It can debug UEFI application running on the real hardware. But it's expensive and the hardware you debugging has to have a hardware debug port available. It's not hard to find on desktops but on the production laptops it is a rare beast! So you have to solder the connector if you need to debug a specific platform.
I case of UEFI driver development even HW Debugger is not much of a help because you have to have a debug built of the UEFI firmware (BIOS) on the platform installed in order to use a debugger.
I have such setup. I need to program on some embedded device which in spec says to run Linux (although when you turn on the device, clearly the display doesn't show anything linux related - small display).
The embedded device has its own SDK.
Now, I thought using valgrind to check for memory management/allocation.
Can I use valgrind to check a program written for my device?
The problem I see is that the program might contain some device specific SDK calls, hence the program might not run on ordinary fedora linux that I run on my desktop for example.
What are my options?
Running valgrind on embedded devices can be quite challenging, if not impossible.
What you can do is to create unit tests, and execute them using valgrind on the host platform. That is a way to at least check memory problems of part of the code.
Other option is to use platform emulation, and run programs in emulators (again on the host system). QEMU is quite famous open source emulator.
Perhaps.
Make sure you really run Linux, of course.
Figure out the hardware platform; Valgrind supports quite a few platforms but not all.
Consider whether your platform has resources (memory and CPU speed) to spare; running Valgrind is quite costly.
If all of those check out ok, then you should be able to run Valgrind, assuming of course you can get it onto the target machine. You might need to build and install it yourself, of course.
I assume you have some form of terminal/console access, i.e. over serial port, telnet, or something that you can use to run programs on the target.
UPDATE: Based on feedback in comments, I'm starting to doubt the possibility for you to run Valgrind on your particular device.
I need to debug a C program that includes posix threads, socket programming (udp client, server). I use ubuntu 12.04 and as IDE/SDK, Qt Creator 2.4.1 and Netbeans IDE 7.1.2. I know they use gdb for debugging.
When I start to debug my program, the program stops running after 5 min or so and neither Qt Creator or Netbeans output any error or warning, although I use debugging feature and my program suppose to listen for a UDP port.
I use printf for all line of my code, and I can see that my program works as it suppose to and listen the UDP port and waits. I can not figure the problem out why it stops without any reason and since IDEs that I am using do not show any debug error, warning, I can not think any reason.
I wonder if anyone can suggest me a debug program that monitors all/some variables and threads during the run time. Thank you.
An old, but reliable tool is ddd, which is basically the gdb GUI wrapper. Although, I usually do debugging directly with Emacs, ddd is the tool that you'll be able to run on almost all *nix platforms.
gdb isn't too comfortable but always available.
To do runtime analysis of different types, especially checking memory access, Valgrind (see here for docs) might be the tool of choice.
Update: I'm referring to *IX systems. For Windows gbd also works in the cygwin enviroment. Nativly there is VC Express, which is free and includes IDE and debugger.
I'm not quite sure what debugger is used for your kind of application. The only debugger I know about on Linux is gdb. It along with printf statements is all I need.
gdb is simple, though not "too comfortable" as #alk said, but seems to be ubiquitous.
There is also Eclipse, and that's quite a nice development and debugging platform, too.
I have learned C and I would like to start to improve open source software. I would like to hack away one irritating bug in GTK+. To see the bug I need to use Gedit.
How can I download the sources of GTK+ and gedit and compile both of them so that I can see where the bug is? And I have never used any debugger in Linux so is there somewhere a tutorial for that?
You can get information about downloading and compiling of gedit here:
http://projects.gnome.org/gedit/developers.html
My Debugger of choice is GDB:
http://www.gnu.org/software/gdb/
GDB is a console application that may be hard to handle for a beginner. Try an IDE like Eclipse that provides a GUI to GDB.
Almost all Linux debuggers are front-ends for or adaptations of the gdb debugger. You should therefore learn how to use this first, preferably by starting on
small programs of your own construction, not giant FOSS codebases. The gdb manual,
available from here is actually a pretty good tutorial.
The information on building and installing GTK+ should be here:
http://www.gtk.org/development.html
The sources should be here:
http://www.gtk.org/download-linux.html
You can check out gdb:
http://www.gnu.org/software/gdb/ That's a pretty standard linux debugger. I would spend time with it on something simple first, or get an IDE that uses it. Learning gdb can be worth the time though.
gdb is a dinosaur which should long since have been made extinct. Debugging is one area where (gasp!) Windows beats Unix. Having got that off my chest, I advise you to start with the Data Display Debugger (DDD) graphical front end to gdb. Yes, the GUI is quaint, but you will be far more productive, quicker, than if you start with gdb.
Also don't overlook valgrind for finding and diagnosing memory errors. The KDE project actually mandates use of valgrind; I'm not sure about Gnome.
It is possible that you won't see the bug if you download the latest gedit and gtk+ sources. It might be fixed in the latest sources or the latest sources might be different enough to not trigger your bug.
What Linux distribution are you running?
First of all I'd suggest consulting your distribution's bug database to see if someone has filed a similar bug. If you don't find anything, I'd suggest using your distribution's tools to obtain the source that corresponds to the binary that you have installed on your sytem (e.g. apt-get source libgtk-2.0 on Debian or Ubuntu).
Also, your distribution might also make a debug package available (e.g. libgtk2.0-0-dbg on Debian) which will let you run a debugger on the binary that you already have without requiring the source. While this is no substitute for having the sources, it can be useful for running valgrind or making sense out of a core file.