Proyecciones

■

Question 75 Separate the first assignment into two modules. the first module will store all functions defined in

. the second will have the entry point and will call some of these functions.

■

Question 76 take one of the standard linux utilities (from coreutils). Study its object file structure using

and

.

The things we observed in this section apply in most situations. However, there is a bigger picture of different code models that affect the addressing. We will dive into those details in Chapter 15 after getting more familiar with assembly and C. There we will also revise the dynamic libraries again and introduce the notions of Global Offset Table and Procedure Linkage Table.

5.3.5 Loader

Loader is a part of the operating system that prepares executable file for execution. It includes mapping its relevant sections into memory, initializing .bss, and sometimes mapping other files from disk.

The program headers for a file symbols.asm, shown in Listing 5-22, are shown in Listing 5-32.

Listing 5-32. symbols_pht

> nasm -f elf64 symbols.asm

> nasm -f elf64 executable_object.asm

> ld symbols.o executable_object.o -o main

> readelf -l main

Elf file type is EXEC (Executable file) Entry point 0x4000d8

There are 2 program headers, starting at offset 64

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000e3 0x00000000000000e3 R E 200000 LOAD 0x00000000000000e4 0x00000000006000e4 0x00000000006000e4 0x0000000000000010 0x000000000200001c RW 200000 Section to Segment mapping:

Segment Sections...

00 .text 01 .data .bss

The table tells us that two segments are present.

1. 00 segment

• Is loaded at 0x400000 aligned at 0x200000.

• Contains section .text.

• Can be executed and can be read. Cannot be written to (so you cannot overwrite code).

2. 01 segment

• Is loaded at 0x6000e4 aligned to 0x200000.

• Can be read and written to.

Alignment means that the actual address will be the closest one to the start, divisible by 0x200000.

Thanks to virtual memory, you can load all programs at the same starting address. Usually it is 0x400000.

There are some important observations to be made:

• Assembly sections with similar names, defined in different files, are merged.

• A relocation table is not needed in a pure executable file. Relocations partially remain for shared objects.

Let’s launch the resulting file and see its /proc/<pid>/maps file as we did in Chapter 4. Listing 5-33 shows its sample contents. The executable is crafted to loop infinitely.

Listing 5-33. symbols_maps

7ffe19d40000-7ffe19d42000 r--p 00000000 00:00 0 [vvar]

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

As we see, the program header is telling us the truth about section placement.

■

Note in some cases, you will find that the linker needs to be finely tuned. the section loading addresses and relative placement can be adjusted by using linker scripts, which describe the resulting file. Such cases usually occur when you are programming an operating system or a microcontroller firmware. this topic is beyond the scope of this book, but we recommend that you look at [4] in case you encounter such a need.

5.4 Assignment: Dictionary

This assignment will further advance us to a working Forth interpreter. Some things about it might seem forced, like the macro design, but it will make a good foundation for an interpreter we are going to do later.

Our task is to implement a dictionary. It will provide a correspondence between keys and values.

Each entry contains the address of the next entry, a key, and a value. Keys and values in our case are null-terminated strings.

The dictionary entries form a data structure are called a linked list. An empty list is represented by a null pointer, equal to zero. A non-empty list is a pointer to its first element. Each element holds some kind of value and a pointer to the next element (or zero, if it is the last element).

Listing 5-34 shows an exemplary linked list, holding elements 100, 200, and 300. It can be referred to by a pointer to its first element, that is, x1.

Listing 5-34. linked_list_ex.asm

Linked lists are often useful in situations that have numerous insertions and removals in the middle of the list. Accessing elements by index, however, is hard because it does not boil down to simple pointer addition. Linked list elements’ mutual positions in flat memory are usually not predictable.

In this assignment the dictionary will be constructed statically as a list and each newly defined element will be prepended to it. You have to use macros with local labels and symbol redefinition to automatize the linked list creation. We explicitly instruct you to make a macro colon with two arguments, where the first will hold a dictionary key string and the second will hold the internal element representation name. This differentiation is needed because key strings can sometimes contain characters which are not parts of valid label names (space, punctuation, arithmetic signs, etc.). Listing 5-35 shows an example of such a dictionary.

Listing 5-35. linked_list_ex_macro.asm section .data

colon "third word", third_word db "third word explanation", 0 colon "second word", second_word db "second word explanation", 0 colon "first word", first_word db "first word explanation", 0

The assignment will contain the following files:

1. main.asm 2. lib.asm 3. dict.asm 4. colon.inc

Follow these steps to complete the assignment:

1. Make a separate assembly file containing functions that you have already written in the first assignment. We will call it lib.o.

Do not forget to mark all necessary labels global, otherwise they won’t be visible outside of this object file!

2. Create a file colon.inc and define a colon macro there to create dictionary words.

This macro will take two arguments:

• Dictionary key (inside quotes).

• Assembly label name. Keys can contain spaces and other characters, which are not allowed in label names.

Each entry should start with a pointer to the next entry, then hold a key as a null-terminated string. The content is then directly described by a programmer—for example, using db directives, as in the example shown in Listing 5-35.

3. Create a function find_word inside a new file dict.asm. It accepts two arguments:

(a) A pointer to a null terminated key string.

(b) A pointer to the last word in the dictionary. Having a pointer to the last word defined, we can follow the consecutive links to enumerate all words in the dictionary.

find_word will loop through the whole dictionary, comparing a given key with each key in dictionary. If the record is not found, it returns zero; otherwise it returns record address.

4. A separate include file words.inc to define dictionary words using the colon macro. Include it in main.asm.

5. A simple _start function. It should perform the following actions:

• Read the input string in a buffer of maximum 255 characters long.

• Try to find this key in dictionary. If found, print the corresponding value. If not, print an error message.

Do not forget: all error messages should be written in stderr rather than stdout!

We ship a set of stub files (see Section 2.1 “Setting Up the Environment”); you are free to use them.

An additional Makefile describes the building process; type make in the assignment directory to build an executable file main. A quick tutorial to the GNU Make system is available in Appendix B.

As in the first assignment, there is a test.py file to perform automated tests.

5.5 Summary

In this chapter we have looked at the different compilation stages. We have studied the NASM

macroprocessor in detail and learned conditionals and loops. Then we talked about three object file types:

relocatable, executable, and shared. We elaborated the ELF file structure and observed the relocation process performed by the linker. We have touched on the shared object files, and we will revisit them again in the Chapter 15.