An Approach to core dump in minix3

Hey people,
I have been trying to work around implementing core dump in minix3.A clear understanding of what core dump is necessary for its design. I will start with what a core file is.

The core file contains the memory image of the process, which can be used for debugging purposes.A core file is created when various errors(depends on how dumping is implemented) occur. Errors such as memory-address violations, illegal instructions, bus errors, and user-generated quit signals, commonly cause this core dump. The core file that is created contains a memory image of the terminated process.

The contents of a core dump are organized sequentially in the core file.It may follow any data structure to produce dump.Below is a rough idea of what things can be included.

Core header -> Defines basic information about the core dump, and contains offsets that locate the remainder of the core dump information.
User stack -> Contains a copy of the user stack at the time of the core dump.
Data area -> Contains the user data section.
Memory mapped regions -> Contains the anonymously mapped regions.

Process Control Blocks :

A process control block (PCB) exists for each process, describing the state of that process by maintaining the LDT, as well as saved register values, used to save the process state while a process is waiting to be scheduled. The PCB is a struct proc, containing important information about one process, including the process number and status. Also accessible through the PCB, via the p_map memory map, are the base addresses and physical and virtual sizes of the three segments of each process: (1)the text, (2)data, and (3)stack segments.

In minix architecture the microkernel, file system, and memory manager all maintain their own process tables but keep strict correspondence between these entries.The complete state of a process is defined by the process' data in memory, plus the information in its process table slot.

Some Merits of GDB

There are some impressive features of GDB which I would like to point out :

1. GDB targets a good range of processors which includes Alpha, ARM, AVR, H8/300, System/370, System 390, X86 and its 64-bit extension X86-64, IA-64 "Itanium", Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, and VAX.

2.GDB offers a remote mode.gdbserver can be used to remotely debug the program

3.The file caching mechanism is embedded within BFD and allows the application to open as many BFDs as it wants without regard to the underlying operating system's file descriptor limit.

Some features which I would like to have :

Display of variable values in a tree structure by a single command.

Various Aspects of a GNU Debugger

This blog is intended to give a brief overview of GDB and some internal features. GDB is an interactive tool. GDB should be responsive to the user.

GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

* Start your program, specifying anything that might affect its behavior.
* Make your program stop on specified conditions.
* Examine what has happened, when your program has stopped.
* Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.


GDB consists of three major subsystems:

1. User interface: The user interface consists of several actual interfaces, plus supporting code.

2. Symbol handling (the symbol side): The symbol side consists of object file readers, debugging info interpreters, symbol table management, source language expression parsing, type and value printing.

3.Target system handling (the target side): The target side consists of execution control, stack frame analysis, and physical target manipulation.


GDB uses a technique called prologue analysis to find frame sizes and saved registers. A prologue analyzer disassembles the function's machine code starting from its entry point, and looks for instructions that allocate frame space, save the stack pointer in a frame pointer register, save registers, and so on.

Breakpoint Handling:
Hardware breakpoints are sometimes available as a builtin debugging features with some chips. Typically these work by having dedicated register into which the breakpoint address may be stored. If the program counter ever matches a value in a breakpoint registers, the CPU raises an exception and reports it to gdb.