CHAPTER 5. WRITING, BUILDING, AND LOADING YOUR
KERNEL 47
0000001A 5D pop ebp
0000001B C3 retFirstly, notice how we can differntiate between assembly code of the two functions
by looking for the tell-taleretinstruction that always appears as the last instruction
of a function. Next, notice how the upper function uses the assembly instructioncall,
which we know is used to jump to another routine from which usually we expect to
return. This must be ourcallerfunction, that is callingcalleefunctionat off-
set0x14of the machine code. The most interesting lines here are those immediately
before the call, since they are somehow ensuring that the argumentmyargis passed
tocalleefunction. After establishing its stack frame, as we have seen to be com-
mon to all functions,callerfunctionallocates 8 bytes on the top of the stack (sub
esp,byte +0x8), then stores our passed value,0xdede, into that stack space (mov dword
[esp],0xdede).
So let’s see howcalleefunctionaccesses that argument. From offset0x14, we
see thatcalleefunctionestablishes its stack frame as usual, but then look at what it
stores in theeaxregister, a register that we know from our earlier analysis is used to
hold a function’s return value: it stores the contents of address[ebp + 0x8]. Here we
have to remind ourselves again of that confusing fact that the stack grows downwards
in memory, so in terms of logically-more-sensible upward growing stack,ebp + 0x8is
8 bytesbelowour stack’s base, so we are actually reaching into the stack frame of the
function that called us to get the argument’s value. This is what we’d expect, of course,
because the caller put that value onto the top of their stack, then we put our stack base
at the top of their stack to establish our stack frame.
It is very useful to know the calling convention used by any high-level language com-
piler when interfacing its code in assembly. For example, the default calling convention
of C is to push arguments onto the stack in reverse order, so the first argument is on the
top of the stack. To mix up the order of arguments would certainly cause the program
to perform incorrectly, and likely crash.
5.1.4 Pointers, Addresses, and Data
When working in a high-level language we can easily find ourselves forgetting about the
fact that variables are simply references to allocated memory addresses, where sufficient
space has been reserved to accomodate their particular data type. This is because, in
most cases when we are dealing with variables, we are really only interested in the values
that they hold, rather than where they reside in memory. Consider the following snippet
of C code:
int a = 3;
int b = 4;
int total = a + b;Now that we have more of an awareness about how the computer will actually perform
these simple C instructions, we could make a well informed assumption that the instruc-
tionint a = 3;will involve two main steps: firstly, at least 4 bytes (32 bits) will be
reserved, perhaps on the stack, to hold the value; then, the value 3 will be stored at the
reserved address. The same would be the case for the second line. And in the lineint