From: Sean Chen <sean.chen1234@gmail.com>
To: Hui Zhu <teawater@gmail.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: System call support in reversible debugging
Date: Mon, 30 Nov 2009 16:29:00 -0000 [thread overview]
Message-ID: <5e81cb500911300539r52e8be5dva54d32c734978021@mail.gmail.com> (raw)
In-Reply-To: <daef60380911300427p20b2e9bege4087bbcd18bc82a@mail.gmail.com>
On Mon, Nov 30, 2009 at 8:27 PM, Hui Zhu <teawater@gmail.com> wrote:
> Cool! I think your explain is very clear. Thanks. :)
>
> Hui
>
> On Sun, Nov 29, 2009 at 01:40, Michael Snyder <msnyder@vmware.com> wrote:
>> Sean Chen wrote:
>>>
>>> On Sat, Nov 28, 2009 at 2:07 AM, Michael Snyder <msnyder@vmware.com>
>>> wrote:
>>>>
>>>> These are two separate questions. I think the one you started with
>>>> is can gdb record a system call, and the answer is "yes".
>>>>
>>>>
>>>> The issue with mmap has a lot of history, and rather than try to
>>>> explain it, I urge you to look up the threads which have "mmap"
>>>> or "sbrk" in the title) and read them.
>>>>
>>>>
>>>
>>> Thanks for the explanation. That is very kind of you.
>>>
>>> I am confused about the first question. How does gdb record the system
>>> call instructions? You know, they are in the kernel space? It seems
>>> that I must have made a mistake somewhere. Please help to clarify.
>>>
>>> Thanks in advance.
>>
>> Sean,
>>
>> I wish I understood this better -- maybe Hui will explain it more.
>>
>> As I understand it, each system call is recorded as if it were a
>> single instruction. Instead of 'tracing' into the system code,
>> we know the specific side effects for each system call, and for
>> instance if the syscall will write to a buffer we take a snapshot
>> of that buffer first.
>>
>> Michael
>>
>>
>
Hi Michael and Hui,
I am sorry for my late response.
Thanks for your explanation. So we can’t treat the system calls as a
black box and have to understand the detailed implementation of each
system call. I think we need to understand every lines of the code in
the system calls carefully enough, and care about the difference of
the Linux kernel since the code of system calls might change
frequently. Do we have any good ways to do it?
Thanks.
--
Best Regards,
Sean Chen
next prev parent reply other threads:[~2009-11-30 13:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-27 15:11 Sean Chen
2009-11-27 15:42 ` Hui Zhu
2009-11-27 18:11 ` Sean Chen
2009-11-28 1:45 ` Hui Zhu
2009-11-28 17:44 ` Sean Chen
2009-11-29 2:24 ` Michael Snyder
2009-11-29 2:24 ` Sean Chen
2009-11-30 12:27 ` Michael Snyder
2009-11-30 16:03 ` Hui Zhu
2009-11-30 16:29 ` Sean Chen [this message]
2009-12-01 11:32 ` Jakob Engblom
2009-12-01 20:21 ` Greg Law
2009-12-02 17:16 ` Jakob Engblom
2009-12-03 3:05 ` Sean Chen
[not found] ` <4B142C54.7070207@vmware.com>
2009-12-03 2:57 ` Sean Chen
2009-12-03 9:00 ` Jakob Engblom
2009-12-04 15:40 ` Sean Chen
2009-12-03 16:57 ` Michael Snyder
2009-12-04 15:46 ` Sean Chen
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=5e81cb500911300539r52e8be5dva54d32c734978021@mail.gmail.com \
--to=sean.chen1234@gmail.com \
--cc=gdb@sourceware.org \
--cc=teawater@gmail.com \
/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