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).
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.
The initial entry point for an image is a single value that is stored in the ELF header file. For programs loaded into RAM by an operating system or boot loader, the loader starts the image execution by transferring control to the initial entry point in the image. An image can have only one initial entry point.
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.
I'm not sure which part confused you so I'll try to cover them all:
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With