Why do the addresses in my assembler dump differ from the addresses of registers?
I have a very basic program that I compiled with
gcc -m32 -g -o hello32.out hello.c
When I run disassemble main in gdb I get the following output:
0x0000051d <+0>: lea ecx,[esp+0x4]
0x00000521 <+4>: and esp,0xfffffff0
0x00000524 <+7>: push DWORD PTR [ecx-0x4]
0x00000527 <+10>: push ebp
0x00000528 <+11>: mov ebp,esp
0x0000052a <+13>: push ebx
0x0000052b <+14>: push ecx
0x0000052c <+15>: sub esp,0x10
0x0000052f <+18>: call 0x420 <__x86.get_pc_thunk.bx>
0x00000534 <+23>: add ebx,0x1aa4
0x0000053a <+29>: mov DWORD PTR [ebp-0xc],0x0
... [truncated for brevity]
However, when I run
(gdb) break main
(gdb) run
(gdb) info register eip
I get
eip 0x5655553a 0x5655553a <main+29>
Why is main+29 shown as 0x0000053a in the assembler dump but 0x5655553a when the address of eip is given?
gcc assembly x86 gdb
add a comment |
I have a very basic program that I compiled with
gcc -m32 -g -o hello32.out hello.c
When I run disassemble main in gdb I get the following output:
0x0000051d <+0>: lea ecx,[esp+0x4]
0x00000521 <+4>: and esp,0xfffffff0
0x00000524 <+7>: push DWORD PTR [ecx-0x4]
0x00000527 <+10>: push ebp
0x00000528 <+11>: mov ebp,esp
0x0000052a <+13>: push ebx
0x0000052b <+14>: push ecx
0x0000052c <+15>: sub esp,0x10
0x0000052f <+18>: call 0x420 <__x86.get_pc_thunk.bx>
0x00000534 <+23>: add ebx,0x1aa4
0x0000053a <+29>: mov DWORD PTR [ebp-0xc],0x0
... [truncated for brevity]
However, when I run
(gdb) break main
(gdb) run
(gdb) info register eip
I get
eip 0x5655553a 0x5655553a <main+29>
Why is main+29 shown as 0x0000053a in the assembler dump but 0x5655553a when the address of eip is given?
gcc assembly x86 gdb
2
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)
– Peter Cordes
Nov 15 '18 at 0:49
add a comment |
I have a very basic program that I compiled with
gcc -m32 -g -o hello32.out hello.c
When I run disassemble main in gdb I get the following output:
0x0000051d <+0>: lea ecx,[esp+0x4]
0x00000521 <+4>: and esp,0xfffffff0
0x00000524 <+7>: push DWORD PTR [ecx-0x4]
0x00000527 <+10>: push ebp
0x00000528 <+11>: mov ebp,esp
0x0000052a <+13>: push ebx
0x0000052b <+14>: push ecx
0x0000052c <+15>: sub esp,0x10
0x0000052f <+18>: call 0x420 <__x86.get_pc_thunk.bx>
0x00000534 <+23>: add ebx,0x1aa4
0x0000053a <+29>: mov DWORD PTR [ebp-0xc],0x0
... [truncated for brevity]
However, when I run
(gdb) break main
(gdb) run
(gdb) info register eip
I get
eip 0x5655553a 0x5655553a <main+29>
Why is main+29 shown as 0x0000053a in the assembler dump but 0x5655553a when the address of eip is given?
gcc assembly x86 gdb
I have a very basic program that I compiled with
gcc -m32 -g -o hello32.out hello.c
When I run disassemble main in gdb I get the following output:
0x0000051d <+0>: lea ecx,[esp+0x4]
0x00000521 <+4>: and esp,0xfffffff0
0x00000524 <+7>: push DWORD PTR [ecx-0x4]
0x00000527 <+10>: push ebp
0x00000528 <+11>: mov ebp,esp
0x0000052a <+13>: push ebx
0x0000052b <+14>: push ecx
0x0000052c <+15>: sub esp,0x10
0x0000052f <+18>: call 0x420 <__x86.get_pc_thunk.bx>
0x00000534 <+23>: add ebx,0x1aa4
0x0000053a <+29>: mov DWORD PTR [ebp-0xc],0x0
... [truncated for brevity]
However, when I run
(gdb) break main
(gdb) run
(gdb) info register eip
I get
eip 0x5655553a 0x5655553a <main+29>
Why is main+29 shown as 0x0000053a in the assembler dump but 0x5655553a when the address of eip is given?
gcc assembly x86 gdb
gcc assembly x86 gdb
asked Nov 15 '18 at 0:41
Bryan CoxwellBryan Coxwell
548
548
2
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)
– Peter Cordes
Nov 15 '18 at 0:49
add a comment |
2
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)
– Peter Cordes
Nov 15 '18 at 0:49
2
2
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with
-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)– Peter Cordes
Nov 15 '18 at 0:49
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with
-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)– Peter Cordes
Nov 15 '18 at 0:49
add a comment |
1 Answer
1
active
oldest
votes
Your GCC makes PIE executables by default, so there is no fixed base address in the file (and disassembly shows it relative to 0, i.e. offsets rather than absolute addresses).
Once the kernel's ELF program loader has created a running process from the executable (and chosen a virtual address as the base), GDB can show you the actual runtime virtual addresses.
Build with -fno-pie -no-pie
to get position-dependent executables where the runtime address is known from the executable metadata. (You should definitely prefer -fno-pie
for i386 code: without RIP-relative addressing the extra performance / code-size cost of position-independent code is significantly worse than for x86-64.)
Related: 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit x86, and in general.)
GDB - Address of breakpoint is similar to this but not exactly a duplicate.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53310872%2fwhy-do-the-addresses-in-my-assembler-dump-differ-from-the-addresses-of-registers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your GCC makes PIE executables by default, so there is no fixed base address in the file (and disassembly shows it relative to 0, i.e. offsets rather than absolute addresses).
Once the kernel's ELF program loader has created a running process from the executable (and chosen a virtual address as the base), GDB can show you the actual runtime virtual addresses.
Build with -fno-pie -no-pie
to get position-dependent executables where the runtime address is known from the executable metadata. (You should definitely prefer -fno-pie
for i386 code: without RIP-relative addressing the extra performance / code-size cost of position-independent code is significantly worse than for x86-64.)
Related: 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit x86, and in general.)
GDB - Address of breakpoint is similar to this but not exactly a duplicate.
add a comment |
Your GCC makes PIE executables by default, so there is no fixed base address in the file (and disassembly shows it relative to 0, i.e. offsets rather than absolute addresses).
Once the kernel's ELF program loader has created a running process from the executable (and chosen a virtual address as the base), GDB can show you the actual runtime virtual addresses.
Build with -fno-pie -no-pie
to get position-dependent executables where the runtime address is known from the executable metadata. (You should definitely prefer -fno-pie
for i386 code: without RIP-relative addressing the extra performance / code-size cost of position-independent code is significantly worse than for x86-64.)
Related: 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit x86, and in general.)
GDB - Address of breakpoint is similar to this but not exactly a duplicate.
add a comment |
Your GCC makes PIE executables by default, so there is no fixed base address in the file (and disassembly shows it relative to 0, i.e. offsets rather than absolute addresses).
Once the kernel's ELF program loader has created a running process from the executable (and chosen a virtual address as the base), GDB can show you the actual runtime virtual addresses.
Build with -fno-pie -no-pie
to get position-dependent executables where the runtime address is known from the executable metadata. (You should definitely prefer -fno-pie
for i386 code: without RIP-relative addressing the extra performance / code-size cost of position-independent code is significantly worse than for x86-64.)
Related: 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit x86, and in general.)
GDB - Address of breakpoint is similar to this but not exactly a duplicate.
Your GCC makes PIE executables by default, so there is no fixed base address in the file (and disassembly shows it relative to 0, i.e. offsets rather than absolute addresses).
Once the kernel's ELF program loader has created a running process from the executable (and chosen a virtual address as the base), GDB can show you the actual runtime virtual addresses.
Build with -fno-pie -no-pie
to get position-dependent executables where the runtime address is known from the executable metadata. (You should definitely prefer -fno-pie
for i386 code: without RIP-relative addressing the extra performance / code-size cost of position-independent code is significantly worse than for x86-64.)
Related: 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit x86, and in general.)
GDB - Address of breakpoint is similar to this but not exactly a duplicate.
answered Nov 15 '18 at 1:15
Peter CordesPeter Cordes
128k18190327
128k18190327
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53310872%2fwhy-do-the-addresses-in-my-assembler-dump-differ-from-the-addresses-of-registers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
because your GCC makes PIE executables by default, so there is no fixed base address (and disassembly shows it relative to 0). Build with
-fno-pie -no-pie
to get position-dependent executables. Related: GDB - Address of breakpoint. And also 32-bit absolute addresses no longer allowed in x86-64 Linux? for more about PIE (both 32-bit and 64-bit.)– Peter Cordes
Nov 15 '18 at 0:49