From: Greg Law <glaw@undo-software.com>
To: Jakob Engblom <jakob@virtutech.com>
Cc: 'Sean Chen' <sean.chen1234@gmail.com>,
'Hui Zhu' <teawater@gmail.com>,
gdb@sourceware.org
Subject: Re: System call support in reversible debugging
Date: Tue, 01 Dec 2009 20:21:00 -0000 [thread overview]
Message-ID: <4B157A21.9020603@undo-software.com> (raw)
In-Reply-To: <00a701ca7279$f1a03c60$d4e0b520$@com>
Ok, I can't resist jumping in :)
Jakob Engblom wrote:
>
>> 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?
>
> To really do this right, you should use a full-system simulator that lets you
> debug OS and user code at the same time, as it is attacking the system at the
> hardware/software interface level.
It all depends what you want to do.
If you want to debug kernel code, then absolutely you need a full system
approach, such as Simics or VMware offers. Similarly if you want to
debug the whole host. But if you're debugging just a process (i.e. the
classic use-case of gdb), you may not want to wind back the state of the
entire (virtual) machine. In which case, something like UndoDB or prec
is more appropriate.
I don't claim either approach is superior. It's a bit like native
debugging versus remote debugging. Which one makes most sense all
depends on what it is you're trying to debug.
Greg
--
Greg Law, Undo Software http://undo-software.com/
next prev parent reply other threads:[~2009-12-01 20:21 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
2009-12-01 11:32 ` Jakob Engblom
2009-12-01 20:21 ` Greg Law [this message]
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=4B157A21.9020603@undo-software.com \
--to=glaw@undo-software.com \
--cc=gdb@sourceware.org \
--cc=jakob@virtutech.com \
--cc=sean.chen1234@gmail.com \
--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