Why is the entry point address in my executable 0x8048330? (0x330 being the offset of .text section)

Question

I wrote a small program to add two integers and on using readelf -a executable_name it showed the entry point address in elf header as:

Entry point address: 0x8048330

How does my executable know this address beforehand even before loader loads it in memory? elf_format.pdf says this member gives the virtual address to which the system first transfers control, thus starting the process. Can anyone please explain what is the meaning of this statement and what is the meaning of virtual address here?

Also let me know, from where the executable file gets the value of 0x8048330 as entry point address. Just for cross check I compiled another program and for that also, the entry point address remains the same value 0x8048330 (offset of .text section being 0x330 in both the cases).

Solution 1

For first question:

the entry point you saw, 0x8048330, is a virtual memory address (in the opposite, is physical memory). This means your executive doesn't have to know what physical address to map. (after it loads with a loader) It doesn't even have the access to the physical memory. To the process of your program, your .text section always starts from 0x8048330, your system (OS and hardware) will then map it (the virtual address) to the physical memory at run-time.

mapping and managing physical memory is a lot of things, you can check on Google for more information.

For the second question

I'm not sure which part confused you so I'll try to cover them all:

• Could more than one program have same entry point?

Yes, there could be another program with the same entry point 0x8048330. because this address is virtual, the programs will be mapped to different physical memory at run-time when you try to run them at the same time.

• Does the entry always 0x8048330?

Well, Linux executives are start from 0x8048000, but the offset of .text section is related to other sections length. So no, it could be 0x8048034 or anything else.

• Why it always start from 0x8048000?

I think it's kind of history thing, the designer of Linux picked this one for some unknown or even random reason. you can refer this thread to see what under that area.

Solution 2

The entry address is set by the link editor, at the time when it creates the executable. The loader maps the program file at the address(es) specified by the ELF headers before transferring control to the entry address.

To use a concrete example, consider the following:

% file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, \
    for GNU/Linux 2.6.15, not stripped
% readelf -e a.out
... snip ...
Elf file type is EXEC (Executable file)
Entry point 0x8048170
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0x7cca6 0x7cca6 R E 0x1000
  LOAD           0x07cf98 0x080c5f98 0x080c5f98 0x00788 0x022fc RW  0x1000
... snip ...

The first program header specifies that the contents of the file at file offset 0 should be mapped to virtual address 0x08048000. The file and memory sizes for this segment are 0x7cca6 bytes. This segment is to be mapped in readable and executable but not writable (it contains the program's code).

The entry point address specified in the ELF header is 0x8048170, which falls inside the region containing program code.

The book "Linkers and Loaders" by John Levine is a good resource to consult on matters related to link editors and loaders.

Solution 3

About the virtual address question:

Normal userland applications work with virtual addresses which means they don't access directly the memory space. The OS (with the help of some microprocessor's special functions) maps this virtual addresses to physical addresses.

This way, the OS prevents applications from reading/writing into other applications memory or OS reserved memory. Also, this allows the paging of memory (use hard disk as memory) in a transparent way for the application.

Comments

[Alexey Frunze]

Look up Wikipedia for virtual address or virtual address translation or virtual memory, etc, if you're interested. Unless you are making your own OS with any of those, for your purposes it's not needed to know what they are, just drop the word virtual. There are also tools, which should be able to tell you a lot about executables. Try objdump.