|
⇤ ← Revision 1 as of 2006-10-10 20:59:25
Size: 183
Comment:
|
Size: 1942
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
=== Notation === All kernel files that are referenced in this paper are specifed by a path name relative to the kernel's root directory. For example the `setup.c` file for the PowerPC architecture would be given as: `arch/ppc/kernel/setup.c`. A specific function (e.g. `early_init`) within a given file is expressed as `arch/ppc/kernel/setup.c:early_init()` regardless of what parameters it accepts (if any) and what it returns (if anything). === Architecture === As far as I know, this mechanism is not architecture-dependent. I actually found it while tracing through the boot process of the PowerPC architecture, but my code tests were performed on an x86-based machine. The code that makes this work is in the kernel's `init/` directory, which (as is my understanding), contains initialization code which is used by all architectures. The ability to use this mechanism depends more on specific support given by the GNU tools and the ELF executable format rather than architecture-specific support. === Tools === Peering into the world of object files is made easier using the tools: * '''objdump''' * '''nm''' and * '''readelf''' ==== "objdump -t" output format ==== I often dump the symbols of a file using `objdump -t`. I can't seem to easily locate any documentation on the output format so I've included some quick notes here. A typical use of this tool would look something like the following: {{{ [trevor]$ objdump -t add.o add.o: file format elf32-i386 SYMBOL TABLE: 00000000 l df *ABS* 00000000 add.c 00000000 l d .text 00000000 00000000 l d .data 00000000 00000000 l d .bss 00000000 00000000 l d .comment 00000000 00000000 g F .text 0000000b add }}}` |
Date and Version
I started writing this paper on the 26th of August 2003. The kernel code quoted herein refers to version 2.4.22. The binutils code comes from binutils-1.4.
Notation
All kernel files that are referenced in this paper are specifed by a path name relative to the kernel's root directory. For example the setup.c file for the PowerPC architecture would be given as: arch/ppc/kernel/setup.c. A specific function (e.g. early_init) within a given file is expressed as arch/ppc/kernel/setup.c:early_init() regardless of what parameters it accepts (if any) and what it returns (if anything).
Architecture
As far as I know, this mechanism is not architecture-dependent. I actually found it while tracing through the boot process of the PowerPC architecture, but my code tests were performed on an x86-based machine. The code that makes this work is in the kernel's init/ directory, which (as is my understanding), contains initialization code which is used by all architectures. The ability to use this mechanism depends more on specific support given by the GNU tools and the ELF executable format rather than architecture-specific support.
Tools
Peering into the world of object files is made easier using the tools: * objdump * nm and * readelf
"objdump -t" output format
I often dump the symbols of a file using objdump -t. I can't seem to easily locate any documentation on the output format so I've included some quick notes here. A typical use of this tool would look something like the following:
[trevor]$ objdump -t add.o add.o: file format elf32-i386 SYMBOL TABLE: 00000000 l df *ABS* 00000000 add.c 00000000 l d .text 00000000 00000000 l d .data 00000000 00000000 l d .bss 00000000 00000000 l d .comment 00000000 00000000 g F .text 0000000b add
`