Practical Session 4

Labels Definition - advanced label: (pseudo) instruction operands ; comment valid characters in labels are: letters, numbers, _, $, ~,., and ? first character can be: letter, _, ? and. (. has a special meaning) label can be prefixed with a $ to indicate that it is intended to be read as an identifier and not a reserved word Example: $eax: mov eax, 2

Local Labels Definition A label beginning with a single period (.) is treated as a local label, which means that it is associated with the previous non-local label. Example: label1: mov eax, 3.loop: dec eax jne.loop ret label2: mov eax, 5.loop: dec eax jne.loop ret Each JNE instruction jumps to the closest.loop, because the two definitions of.loop are kept separate. (this is indeed label1.loop) (this is indeed label2.loop)

How to run Linux from Window Go to Run the following executable Use “lvs.cs.bgu.ac.il” or “lace.cs.bgu.ac.il” host name and click ‘Open’ Use your Linux username and password to login lace server Go to  Choose any free Linux computer  Connect to the chosen computer by using “ssh –X cs302six1-4” (maybe you would be asked for your password again) cd (change directory) to your working directory

section.data numeric:DD 0x string:DB 'abc' answer:DD0 section.text global _start ;entry point (main) _start: pushad; backup registers push dword 2; push argument #2 push dword 1; push argument #1 CALL myFunc; call the function myFunc returnAddress: mov [answer], eax; retrieve return value from EAX add esp, 8; "delete" function arguments popad mov ebx,0; exit program mov eax,1 int 0x80 myFunc: ; myFunc gets two parameters a and b returns a+b push ebp ; save previous value of ebp mov ebp, esp ; set ebp to point to myFunc frame mov eax, dword [ebp+8]; get function argument #1 mov ebx, dword [ebp+12]; get function argument #2 myFunc_code: add eax, ebx; eax = 3 returnFrom_myFunc: mov esp, ebp; "delete" local variables of myFunc pop dword ebp; restore previous value of ebp ret; return to the caller Assembly program with no.c file usage – sample.s

GNU Linker ld links together compiled assembly without using.c main file > nasm –f elf sample.s –o sample.o > ld -m elf_i386 sample.o –o sample > sample or with gdb debugger > gdb sample

section.data numeric:DD 0x string:DB 'abc' answer:DD0 section.text global _start _start: pushad push dword 2 push dword 1 CALL myFunc returnAddress: mov [answer], eax add esp, 8 popad mov ebx,0 mov eax,1 int 0x80 myFunc: push ebp mov ebp, esp mov eax, dword [ebp+8] mov ebx, dword [ebp+12] myFunc_code: add eax, ebx returnFrom_myFunc: mov esp, ebp pop dword ebp ret print ‘numeric’ global variable numeric into memory – little endian print ‘string’ global variable string into memory – little endian pushad 0xffffd640 – 0xffffd620= 0x20 = 32 bytes = 8 registers * 4 bytes push function’s arguments into stack CALL myFunc return address

Command-line arguments In Linux, we receive command-line arguments on the stack as execution starts: The first argument is number of arguments (i.e. argc) Each one of the rest of arguments is a pointer to an argument string (i.e. argv[0] (this is the name of the program), argv[1] argv[2], and so on) ld (_start) vs. gcc (main) argv[2] argv[1] argv[0] argc &{argv[0],argv[1],argv[2],…} argc stack This is just like C’s main(int argc, char** argv) ESP

Producing an assembly file for.c file -S (capital letter) to gcc compiler generates an assembly code to.c program. > gcc –m32 –S main.c Producing a listing file -l option to NASM will generates a source-listing file, in which addresses and generated binary code are listed on the left, and the actual source code is listed on the right > nasm -f elf sample.s -l sample.lst Compile the following c code with –S option to observe parameters pass in C, compare to material given in class. #include extern int atoi(char*); void main(int argc, char ** argv) { int m, n; if (argc < 3 ) { printf("use : %s num1 num2\n",argv[0]); return 0; } m = atoi(argv[1]); n = atoi(argv[2]); return; }

Producing a listing file – example 1 The first column (from the left) is simply the line number in the listing and is otherwise meaningless The second column is the relative address, in hex, of where the code will be placed in memory The third column is the actual compiled code Labels (i.e. names suffixed with colons) do not create code, they are simply a way to tell the assembler that those locations have symbolic names. For the normal type of call in 32-bit mode (relative near call), the binary code for ‘CALL myFunc’ is the opcode E8 followed by a 4-byte value that specifies the target address, relative to the next instruction after the call.  Address of myFunc label = 0x1F  Address of the next instruction after the call (i.e. ‘mov [answer], eax’) is 0xA  0x1F-0xA=0x15, and we get exactly the binary code written here ‘E ’

Producing a listing file – example 2 main.c file: #include extern void myFunc (void); int main(void) { myFunc (); // Your assembly code function } func.s file section.rodata STR1: DB "Assembly %s", 10, 0 STR2: DB "code" section.text global myFunc extern printf myFunc: push ebp mov ebp, esp push STR2 push STR1 CALL printf mov esp, ebp pop ebp ret func.lst listing file note that relative address of label of another section (.rodata) is put in “[…]” note that relative address of external function (printf) is not resolved in assembler step (would be resolved after linking by gcc with main.c file)

Producing a listing file – example 2 func.lst listing file > gdb func.out gdb run with executable func.out print EIP register to examine binary code