Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
100401000: 55 push %rbp
100401001: 48 89 e5 mov %rsp,%rbp
100401004: 48 83 ec 20 sub $0x20,%rsp
100401008: 48 8d 0d 71 00 00 00 lea 0x71(%rip),%rcx # 100401080 <main>
10040100f: e8 0c 01 00 00 call 100401120 <msys_crt0>
[...]
--8<---------------cut here---------------end--------------->8---
What is the meaning of these hexadecimal addresses, first column?
Meredith Montgomery <mmontgomery@levado.to> writes:
Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >>%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
100401000: 55 push %rbp
100401001: 48 89 e5 mov %rsp,%rbp
100401004: 48 83 ec 20 sub $0x20,%rsp
100401008: 48 8d 0d 71 00 00 00 lea 0x71(%rip),%rcx # 100401080
<main>
10040100f: e8 0c 01 00 00 call 100401120 <msys_crt0>
[...]
--8<---------------cut here---------------end--------------->8---
What is the meaning of these hexadecimal addresses, first column?
As you suggest, these are the virtual addresses to which that code
will be loaded.
In generally, the executable file (PE COFF for Windows, ELF for Unix/Linux) contains header which describes the layout of the executable file.
https://man7.org/linux/man-pages/man5/elf.5.html
The header will point to a table consisting of the program
sections that need to be loaded when the program is executed.
(called program headers in ELF). Each entry contains the
program address (which could be virtual, or if the code is
running sans the benefit of an operating system, it could
be physical) at which that section of the codefile should be
loaded.
The compiler doesn't generate addresses at all, most addresses in intermediate object files are relocatable (generally relative to
the start of a function) and the final program
addresses are assigned by the linker (or for the case of dynamically
loaded shared objects, the run-time linker/loader).
scott@slp53.sl.home (Scott Lurndal) writes:[snip]
Meredith Montgomery <mmontgomery@levado.to> writes:
Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >>>%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
What is the meaning of these hexadecimal addresses, first column?
The header will point to a table consisting of the program
sections that need to be loaded when the program is executed.
(called program headers in ELF). Each entry contains the
program address (which could be virtual, or if the code is
running sans the benefit of an operating system, it could
be physical) at which that section of the codefile should be
loaded.
That makes sense. Thank you. But, of course, when we see a virtual
address in an executable, we can't assume it will be loaded at that
exact address, right?
I suppose the system reserves itself the right to
relocate these bytes in virtual memory itself. (Perhaps some DLL needs
some of these locations for whatever reason?)
The compiler doesn't generate addresses at all, most addresses in
intermediate object files are relocatable (generally relative to
the start of a function) and the final program
addresses are assigned by the linker (or for the case of dynamically
loaded shared objects, the run-time linker/loader).
That makes sense. (By ``compiler'' I had in mind the whole >executable-production pipeline.) Perhaps an illustration of ``relative
to the start of a function'' is the following COFF hello.o.
--8<---------------cut here---------------start------------->8---
%objdump -d hello.o
hello.o: file format pe-x86-64
Disassembly of section .text:
0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 30 sub $0x30,%rsp
8: 89 4d 10 mov %ecx,0x10(%rbp)
b: 48 89 55 18 mov %rdx,0x18(%rbp)
f: 4c 89 45 20 mov %r8,0x20(%rbp)
[...]
--8<---------------cut here---------------end--------------->8---
The addresses there just serve as counting of the number of bytes the
code takes. For all I know it could even be just a nice output given by >objdump and not actually present in hello.o. I don't know.
Meredith Montgomery <mmontgomery@levado.to> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Meredith Montgomery <mmontgomery@levado.to> writes:
Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >>>>%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
[snip]What is the meaning of these hexadecimal addresses, first column?
The header will point to a table consisting of the program
sections that need to be loaded when the program is executed.
(called program headers in ELF). Each entry contains the
program address (which could be virtual, or if the code is
running sans the benefit of an operating system, it could
be physical) at which that section of the codefile should be
loaded.
That makes sense. Thank you. But, of course, when we see a virtual >>address in an executable, we can't assume it will be loaded at that
exact address, right?
It must, by definition, be loaded at that virtual address.
On Wed, 2021-11-17, Scott Lurndal wrote:
Meredith Montgomery <mmontgomery@levado.to> writes:
scott@slp53.sl.home (Scott Lurndal) writes:[snip]
Meredith Montgomery <mmontgomery@levado.to> writes:
Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >>>>>%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
What is the meaning of these hexadecimal addresses, first column?
The header will point to a table consisting of the program
sections that need to be loaded when the program is executed.
(called program headers in ELF). Each entry contains the
program address (which could be virtual, or if the code is
running sans the benefit of an operating system, it could
be physical) at which that section of the codefile should be
loaded.
That makes sense. Thank you. But, of course, when we see a virtual >>>address in an executable, we can't assume it will be loaded at that
exact address, right?
It must, by definition, be loaded at that virtual address.
Yes, and it has important effects, such as seeing the same addresses
in core dumps and various stack traces.
Shared libraries, on the other hand, are not loaded into predictable >addresses.
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
On Wed, 2021-11-17, Scott Lurndal wrote:
Shared libraries, on the other hand, are not loaded into predictable >>addresses.
While generally true, there was a period of time in the 1980s
when SVR3.2 had a form of COFF static shared library that required loading at a fixed address.
While generally true, there was a period of time in the 1980s
when SVR3.2 had a form of COFF static shared library that required loading at
a fixed address.
There was a period of time in the 1990's, when GNU/Linux distros had the
same thing.
This is why we have "libc.so.6", where the 6 has nothing to do with the
GLibc 2 version number.
Prior to that there were libc4 and libc5 based on GNU C Library 1.
Under libc4, binaries were a.out, and I think shared libraries were
still not relocatable. It may be libc5 that made them relocatable.
libc6 was then based of GNU C Library 2, and so we have that 6 in the >sonames.
Meredith Montgomery <mmontgomery@levado.to> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Meredith Montgomery <mmontgomery@levado.to> writes:
Here's a brief passage from objdump on a MSYS2 system on Windows 10.
--8<---------------cut here---------------start------------->8--- >>>>%objdump.exe -D hello.exe
hello.exe: file format pei-x86-64
Disassembly of section .text:
0000000100401000 <WinMainCRTStartup>:
[snip]What is the meaning of these hexadecimal addresses, first column?
The header will point to a table consisting of the program
sections that need to be loaded when the program is executed.
(called program headers in ELF). Each entry contains the
program address (which could be virtual, or if the code is
running sans the benefit of an operating system, it could
be physical) at which that section of the codefile should be
loaded.
That makes sense. Thank you. But, of course, when we see a virtual >>address in an executable, we can't assume it will be loaded at that
exact address, right?
It must, by definition, be loaded at that virtual address.
If you're not familiar with how virtual memory works, a quick
high-level refresher:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 23:23:54 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,191 |
Messages: | 5,327,626 |