From: 慕冬亮 <mudongliangabcd@gmail.com>
To: gdb@sourceware.org
Subject: Re: instructions logged by Intel PT not always in the address range of NT_FILES
Date: Mon, 19 Sep 2016 04:20:00 -0000 [thread overview]
Message-ID: <CAD-N9QVw8qcxCnV5F2kLjmJ8pDAno7k7NrUrBR69-pjNL5kxiQ@mail.gmail.com> (raw)
In-Reply-To: <CAD-N9QXCEEwmiiTh-B=1HUVno0ufvac7DQqUQC=NFkYWAJUvdw@mail.gmail.com>
I guess that in coredump generated by `gcore`, there is a missing
segment item which contains:
0xb7e1e740 - 0xb7f476dd is .text in /lib/i386-linux-gnu/libc.so.6
The above line is from `info files` when I did `gdb exec coredump`.
--
My best regards to you.
No System Is Safe!
Dongliang Mu
2016-09-18 23:47 GMT-04:00 慕冬亮 <mudongliangabcd@gmail.com>:
> Dear all,
>
> When I did experiment about instructions logged by Intel PT, I found
> an problem: instructions logged by Intel PT are not always in the
> NT_FILES(executable, libraries) of coredump.
>
> I was using the following gdb script to log executed instructions and
> generate coredump:
>
> set pagination off
> set logging on
> set disassembly-flavor intel
> b _start
> r AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> record btrace pt
> continue
> gcore core <= gcore to generate codeump, maybe the problem, not sure.
> info record
> set record instruction-history-size unlimited
> record instruction-history
> quit
>
> $ readelf -n core (Get all the address range of NT_FILES)
> ......
> Page size: 1
> Start End Page Offset
> 0x08048000 0x08049000 0x00000000
> /home/mdl/Work/testsuites/simple2/simple
> 0x08049000 0x0804a000 0x00000000
> /home/mdl/Work/testsuites/simple2/simple
> 0xb7fb4000 0xb7fb6000 0x001ac000
> /lib/i386-linux-gnu/libc-2.23.so
> 0xb7fb6000 0xb7fb7000 0x001ae000
> /lib/i386-linux-gnu/libc-2.23.so
> 0xb7fdb000 0xb7ffd000 0x00000000
> /lib/i386-linux-gnu/ld-2.23.so
> 0xb7ffe000 0xb7fff000 0x00022000
> /lib/i386-linux-gnu/ld-2.23.so
> 0xb7fff000 0xb8000000 0x00023000
> /lib/i386-linux-gnu/ld-2.23.so
>
> When I checked the executed instructions, I found there are
> instructions whose address is not in those NT_FILES. For example,
> 0xb7e1f5f3 <__libc_start_main+243>: call DWORD PTR [esp+0x70]
>
> However, this instruction is from __libc_start_main function that
> should be in libc library.
>
> I don't know what is problem. If I said something wrong, please correct me.
>
> --
> My best regards to you.
>
> No System Is Safe!
> Dongliang Mu
prev parent reply other threads:[~2016-09-19 4:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 3:47 慕冬亮
2016-09-19 4:20 ` 慕冬亮 [this message]
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=CAD-N9QVw8qcxCnV5F2kLjmJ8pDAno7k7NrUrBR69-pjNL5kxiQ@mail.gmail.com \
--to=mudongliangabcd@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