Note that, like the compiler, the linker can output executable les in various for-
mats, some of which may retain meta data from the input object les. This is useful
for executables that are hosted by an operating system, such as the majory of programs
we will write on a platform such as Linux or Windows, since meta data can be retained
to describe how those applications are to be loaded into memory; and for debugging
purposes, for example: the information that a process crashed at instruction address
0x12345678 is far less useful to a programmer than information presented using redun-
dant, non-executable meta-data that a process crashed in function my function, le
basic.c, on line 3.
Anyhow, since we are interested in writing an operating system, it would be no good
trying to run machine code intermingled with meta data on our CPU, since unaware the
CPU will execute every byte as machine code. This is why we specify an output format
of (raw) binary.
The other option we used was -Ttext 0x0, which works in the same way as the org
directive we used in our earlier assembly routines, by allowing us to tell the compiler
to o�set label addresses in our code (e.g. for any data we specify in the code, such as
strings like ``Hello, World'') to their absolute memory addresses when later loaded
to a specic origin in memory. For now this is not important, but when we come to load
kernel code into memory, it is important that we set this to the address we plan to load
to.
Now we have successfully compiled the C code into a raw machine code le, that
we could (once we have gured out how to load it) run on our CPU, so let's see what
it looks like. Luckily, since assembly maps very closely to machine code instructions, if
you are ever given a le containing only machine code, you can easily disassemble it to
view it in assembly. Ah, yes; this is another benet of understanding a little of assembly,
because you can potentially reverse-engineer any software that lands on you lap minus
the original source code, even more successfully if the developer left in some meta data
for you --- which they nearly always do. The only problem with disassmbling machine
code is that some of those bytes may have been reserved as data but will show up as
assembly instructions, though in our simple C program we didn't declare any data. To
see what machine code the compiler actually generated from our C source code, run the
following command:
$ndisasm -b 32 basic.bin > basic.dis
The -b 32 simply tells the disassembler to decode to 32-bit assembly instructions,
which is what our compiler generates. Figure XXX shows the assembly code generated
by gcc for our simple C program.