From: Andrea Cardaci <cyrus.and@gmail.com>
To: gdb@sourceware.org
Subject: Function address incoherence
Date: Sat, 24 Aug 2019 10:27:00 -0000 [thread overview]
Message-ID: <CACMsj9PVtSb_+1gYAUaQPafUd0A-PDuQT5UpvVUWmOHExzxb=w@mail.gmail.com> (raw)
Hi,
I could use some clarification about the following behavior that
initially came up in a issue [1] opened to the gdb-dashboard project.
Basically in some cases it appears that there's some kind of symbol
conflict (this is a bad name but I don't know how to else call it).
I can only reproduce it on a 32 bit Linux machine with the following:
vagrant@ubuntu-xenial:~$ gcc -x c -o test - <<<'int main(){}'
vagrant@ubuntu-xenial:~$ gdb -q --batch test -ex 'b *0' -ex r -ex
disassemble -ex 'p &_start'
Breakpoint 1 at 0x0
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x0
Dump of assembler code for function _start:
=> 0xb7fdba20 <+0>: mov %esp,%eax
0xb7fdba22 <+2>: call 0xb7fdc5c0 <_dl_start>
End of assembler dump.
$1 = (<text variable, no debug info> *) 0x80482e0 <_start>
As you can see, $pc points to 0xb7fdba20 and the disassemble commands
reports that it is part of _start, yet if I print the address of
_start I obtain a different value (0x80482e0). (Using the disassemble
command is just an example, simply printing $pc shows 0xb7fdba20
<_start>.)
Now the latter (0x80482e0) is what appears to be the *real* _start:
vagrant@ubuntu-xenial:~$ readelf -s test | grep ' _start'
60: 080482e0 0 FUNC GLOBAL DEFAULT 14 _start
While the other address (0xb7fdba20) appears to be contained in
/lib/ld-linux.so.2:
0xb7fdb860 - 0xb7ff48fd is .text in /lib/ld-linux.so.2
According to objdump -d /lib/ld-linux.so.2, $pc points at the
following instructions in the _dl_rtld_di_serinfo function:
00000860 <_dl_rtld_di_serinfo@@GLIBC_PRIVATE-0x83c0>:
[...]
a20: 89 e0 mov %esp,%eax
a22: e8 99 0b 00 00 call 15c0 <realloc@plt+0xd80>
So where does the _start reported by the disassemble command comes
from? Is this a GDB bug or I'm missing something here?
Back to the gdb-dashboard issue, I fetch the function address with
gdb.parse_and_eval(frame.name()).address and since frame.name() is
_start, the address that I obtain is 0x80482e0 instead of 0xb7fdba20
thus I end up displaying wrong offsets.
Best,
Andrea
[1]: https://github.com/cyrus-and/gdb-dashboard/issues/70
next reply other threads:[~2019-08-24 10:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-24 10:27 Andrea Cardaci [this message]
2019-08-26 6:54 ` Florian Weimer
2019-08-26 10:22 ` Andrea Cardaci
2019-08-26 7:55 ` Andreas Schwab
2019-08-26 10:22 ` Andrea Cardaci
2019-08-26 16:34 ` Christian Biesinger via gdb
2019-08-26 16:50 ` Andrea Cardaci
2019-08-26 17:39 ` Andrea Cardaci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACMsj9PVtSb_+1gYAUaQPafUd0A-PDuQT5UpvVUWmOHExzxb=w@mail.gmail.com' \
--to=cyrus.and@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).