Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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/


  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