I have done some hacking in windows interrupt table and trying to test it through an application. I don't want to put a break point in the kernel functions which gonna get invoked.(I have modified some of the first level interrupt handlers.) I want to start from the application and then wanna go to the actual hacked part of the code by single stepping. I wanna know if Windbg is good enough to do that? Can I put a breakpoint in my application and then go onto debug windows?
Thanks
You will need to use remote debugging (e.g, from a second computer) to single-step through the kernel. It is impossible to use breakpoints or single-stepping on the kernel of the local machine, as the debugger and other applications rely on the kernel to work.
http://support.microsoft.com/kb/151981
Related
I am in the process of writing a windows 7 kernel driver. Today, I want to have it output debug information via the display. Now I know that I can just use the DbgPrint or the KdPrint functions, but I want to output my string or anything, directly to my monitor. This way, I don't have to fire up Debug View to see my output. This also serves as an educational exercise.
As I understand it, I will have to access the frame buffer for the display and write my values to it, correct? However, I have no clue how to do this. Basically, I want to be able to write something onto the monitor directly, thus it would overlap anything that windows is displaying. I know this might sound weird, but its just for fun.
The main goal is to do this from a KERNEL DRIVER. Not inside a userland process. Note that I am only wanting to use a 640x480 resolution. Not anything higher. If I understand correctly, anything higher than this would require me to write my own display driver for my current video card.
My system setup:
Windows 7 SP1 x86
Intel Pentium 4 # 3.00Ghz
Nvidia GeForce FX 5200
Thanks for all of you help in advance!
Now I know that I can just use the DbgPrint or the KdPrint functions, but I want to output my string or anything, directly to my monitor.
You'll have to go through the display driver. Who says that your computer running windows has a monitor at all?
Even if it has, there won't be a MSDOS-style single framebuffer in RAM that stores your current picture. Modern GPUs just don't work that way any more – instead, operating systems ask them to compose the whole screen of single buffers they hand over for compositing – in simplification: Every window is its own framebuffer, and it's the GPU's job to compose everything to a whole screen picture.
You also can't just write to some memory region from your kernel driver just because you like to do so – a) you don't know where that would be and b) you'd compete with other components, and that would be a bad thing.
EDIT I feel like I should add this for posteriority:
the point is very simple: write a driver that is a driver and not a user interface. That's not the job of a driver. Putting UI functionality into a driver is a bad idea for many reasons, and you simply shouldn't do it.
Currently I'm trying to run qemu-system-arm for armv7 architecture, do some initial setup for paging and then enable MMU.
I run qemu with gdb stub and connect to it then with gdb.
I must have screwed something up with translation tables/registers/etc., the thing is the minute I set MMU-enable bit in control register, gdb can't fetch data from memory anymore: after ni command which executes mmu-enable instruction it doesn't fetch next command and I can't access memory.
Is there any way to look what happens inside Qemu's MMU? Where it takes translation tables from, what calculates etc.
Or should I just recompile it with my additional debug output?
No, there's no way to trace this without modifying QEMU's sources yourself
So I did. For ARM architecture, the relevant code is found in target-arm/helper.c - get_phys_addr* functions.
No, there's no way to trace this without modifying QEMU's sources yourself to add debugging output. This is a specific case of a more general tendency, which is that QEMU's design and approach is largely "run correct code quickly", not to provide detailed introspection into the behaviour of possibly buggy guests. Sometimes, as in this case, there's a nice easy location to add your own debug printing; sometimes, as in the fairly common desire to print all the memory accesses made by the guest, there is nowhere in the C code where tracing can be put to catch all accesses.
When I used QEMU for debugging VM issues in an operating system kernel that I had built with a colleague, I ended up connecting GDB to debug QEMU instead (instead of debugging the guest process inside QEMU).
You can place breakpoints on the MMU table walking function and step through it.
Well, I wrote a code for File I/O with Win32 API.
(I'm using Visual studio 2013)
It just gets two file name(one for source, one for destination) and duplicate one to another.
I used CreateFile, ReadFile, WriteFile.
It's functionally simple. It's not problem. But..
I wanna SEE the system call in these function being called in debugger.
How can I do this?
with Call stack? Disassembler?
So you want to be able to debug not only your own code but also the API itself.
There are different ways to do that.
At the simplest level, just use the debugger from VS2013. You won't be able to trace into kernel code, but all the user level code in the API. But of course as you will use a non debug version of Windows with no symbol table you will only see low-level machine code (*).
If you really want to go deeper, you will have to use the Debugging Tools for Windows. As you say you want to debug system calls, my advice would be to use the Windows Driver Kit, the Windows Symbols, and if you really go down to kernel mode the Windows Remote Debugging Client for Windows (all those tools are available from Windows Dev Center).
All those tools integrate nicely in VisualStudio, but be prepared to hard low level work :-)
(*) You can also use the Microsof Symbol Server to access windows symbolic information - thanks to IInspectable for his comment. But I've never tested.
I have Fedora installed on my PC and I have a Friendly ARM Mini2440 board. I have successfully installed Linux kernel and everything is working. Now I have some image processing program, which I want to run on the board without OS. The only process running on board should be my program. And in that program how can I access the on board camera to take image from, and serial port to send output to the PC.
You're talking about what is often called a bare-metal environment. Google can help you, for example here. In a bare-metal environment you have to have a good understanding of your hardware because you have to take care of a lot of things that the OS normally handles.
I've been working (off and on) on bare-metal support for my ELLCC cross development tool-chain. I have the ARM implementation pretty far along but there is still quite a bit of work to do. I have written about some of my experiences on my blog.
First off, you have to get your program started. You'll need to write some start-up code, usually in assembly, to handle the initialization of the processor as it comes out of reset (or is powered on). The start-up code then typically passes control to code written in C that ultimately directly or indirectly calls your main() function. Getting to main() is a huge step in your bare-metal adventure!
Next, you need to decide how to support your hardware's I/O devices which in your case include the camera and serial port. How much of the standard C (or C++) library does your image processing require? You might need to add some support for functions like printf() or malloc() that normally need some kind of OS support. A simple "hello world" would be a good thing to try next.
ELLCC has examples of various levels of ARM bare-metal in the examples directory. They range from a simple main() up to and including MMU and TCP/IP support. The source for all of it can be browsed here.
I started writing this before I left for work this morning and didn't have time to finish. Both dwelch and Clifford had good suggestions. A bootloader might make your job a lot simpler and documentation on your hardware is crucial.
First you must realise that without an OS, you are responsible for bringing the board up from reset including configuring the PLL and SDRAM, and also for the driver code for every device on the board you wish to use. To do that required adequate documentation of the board and it devices.
It is possible that you can use the existing bootloader to configure the core and SDRAM, but that may not meet your requirement for the only process running on the board should be your image processing program.
Additionally you will need some means of loading and bootstrapping; again the existing Linux bootstrapper may suit.
It is by no means straightforward and cannot really be described in detail here.
I have been asked to write a program in C which should debug another program in C language and then store the value of each variable of every line,loop or function in a log file.
I have been searching over the internet and I found articles on debugging using gdb.
Can I somehow use GDB in my program for this purpose and then store the values of each variable line by line.
I've got basic knowledge of C/C++ so please reply in simple terms.
Thanks
Debuggers depend on some special capability of the hardware, which must be exposed by the operating system (if any).
The basic idea is that the hardware is configured to transfer control to a debugger stub either after every instruction of the target program, or after certain types of instructions such system calls, or those meeting a hardware breakpoint condition. Typically this would look like an interrupt, supervisor exception, or the like - very platform-specific detail.
As mentioned in comments, on Linux, you use the ptrace functionality of the kernel to interact with the debugger support provided by the hardware and the kernel, abstracting away a lot of the hardware-unique detail and managing the permission issues. Typically you must either be the same user id as the process being debugged, or be the superuser (root). Linux's ptrace also gives you an indirect ability to do to things like access the memory (literally, address space) of the target application, something critical to debugger functionality which you cannot ordinarily do from another user-mode program on a multitasking operating system.
Other operating systems will have different methods. Some embedded targets use debug pods which connect your development machine to the embedded board by a few wires. In other cases, debug capability built into the hardware is managed by a small program running on the target processor, which then talks back over a serial or network port to the full debugger program residing on the development machine.
A program such as GDB can do more than just the basics of setting debug stop conditions, dumping registers, and dumping program instructions. Much of its code deals with annotating what it displays based on debug metadata optionally left behind by compilers, walking back through stack frames, and giving the user powerful tools to configure all of this - and of course it does most of this in a target-independent way, with the target-unique code mostly confined to a few interchangeable directories.
You can indeed "drive" GDB from another program - many, many GUI type debuggers do exactly that, existing as graphical front ends for GDB. However, if you were assigned to write a debugger, doing it that way may or may not by consistent with your assignment.