From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [RFA/RFC] Add dump and load command to process record and replay
Date: Sun, 23 Aug 2009 23:43:00 -0000 [thread overview]
Message-ID: <4A91CEEC.5000802@vmware.com> (raw)
In-Reply-To: <daef60380908221034y6c3e44d6j48be017807ded27a@mail.gmail.com>
Hui Zhu wrote:
>
> Hi Michael,
>
> I make a new version patch. It has a lot of changes.
> Remove record_core and add a new target record_core for core target to
> make the code more clear.
> Make the load together with record_open.
>
> Please help me review it.
Hi Hui,
In this review, I'm going to comment only on the parts of the
patch that relate to the record_core_ops (ie. pushing the
record stratum on top of the core file stratum).
Those parts of the patch are much improved. I like this
version a lot better. Thanks for reworking it.
Here's the one major thing that still worries me:
> +static inline void
> +record_exec_entry (struct regcache *regcache, struct gdbarch *gdbarch,
> + struct record_entry *entry, int core)
> +{
> + switch (entry->type)
> + {
> + case record_reg: /* reg */
> + {
> + gdb_byte reg[MAX_REGISTER_SIZE];
> +
> + if (record_debug > 1)
> + fprintf_unfiltered (gdb_stdlog,
> + "Process record: record_reg %s to "
> + "inferior num = %d.\n",
> + host_address_to_string (entry),
> + entry->u.reg.num);
> +
> + regcache_cooked_read (regcache, entry->u.reg.num, reg);
> + regcache_cooked_write (regcache, entry->u.reg.num, entry->u.reg.val);
> + memcpy (entry->u.reg.val, reg, MAX_REGISTER_SIZE);
> + }
> + break;
> +
> + case record_mem: /* mem */
> + {
> + if (!record_list->u.mem.mem_entry_not_accessible)
> + {
> + gdb_byte *mem = alloca (entry->u.mem.len);
> +
> + if (record_debug > 1)
> + fprintf_unfiltered (gdb_stdlog,
> + "Process record: record_mem %s to "
> + "inferior addr = %s len = %d.\n",
> + host_address_to_string (entry),
> + paddress (gdbarch, entry->u.mem.addr),
> + record_list->u.mem.len);
> +
> + if (target_read_memory (entry->u.mem.addr, mem, entry->u.mem.len))
> + {
> + if ((execution_direction == EXEC_REVERSE && !core)
> + || (execution_direction != EXEC_REVERSE && core))
> + {
It troubles me that we have to do one thing if we're going
forward and a different thing if we're going backward,
unles it's a core file, and in that case we do the opposite.
That's just not elegant. We're really going to do the same
thing (swap the contents of target memory with the contents
of the record log) regardless of which direction we're going.
See below for my suggestion.
> + record_list->u.mem.mem_entry_not_accessible = 1;
> + if (record_debug)
> + warning (_("Process record: error reading memory at "
> + "addr = %s len = %d."),
> + paddress (gdbarch, entry->u.mem.addr),
> + entry->u.mem.len);
> + }
> + else
> + error (_("Process record: error reading memory at "
> + "addr = %s len = %d."),
> + paddress (gdbarch, entry->u.mem.addr),
> + entry->u.mem.len);
> + }
> + else
> + {
> + if (target_write_memory (entry->u.mem.addr, entry->u.mem.val,
> + entry->u.mem.len))
> + {
> + if ((execution_direction == EXEC_REVERSE && !core)
> + || (execution_direction != EXEC_REVERSE && core))
And the same thing here. What if we just replace the above
with this? What do you think?
if (target_read_memory (entry->u.mem.addr, mem,
entry->u.mem.len))
{
record_list->u.mem.mem_entry_not_accessible = 1;
if (record_debug)
warning (_("Process record: error reading memory at "
"addr = %s len = %d."),
paddress (gdbarch, entry->u.mem.addr),
entry->u.mem.len);
}
else
{
if (target_write_memory (entry->u.mem.addr,
entry->u.mem.val,
entry->u.mem.len))
{
record_list->u.mem.mem_entry_not_accessible = 1;
if (record_debug)
warning (_("Process record: error writing memory at "
"addr = %s len = %d."),
paddress (gdbarch, entry->u.mem.addr),
entry->u.mem.len);
}
}
next prev parent reply other threads:[~2009-08-23 23:25 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-01 7:31 Hui Zhu
2009-08-01 9:57 ` Eli Zaretskii
2009-08-01 19:20 ` Michael Snyder
2009-08-02 3:18 ` Michael Snyder
2009-08-02 5:58 ` Hui Zhu
2009-08-03 4:12 ` Hui Zhu
2009-08-03 18:29 ` Eli Zaretskii
2009-08-04 1:58 ` Hui Zhu
2009-08-04 2:07 ` Hui Zhu
2009-08-04 18:26 ` Eli Zaretskii
2009-08-04 20:01 ` Michael Snyder
2009-08-05 9:21 ` Hui Zhu
2009-08-05 20:19 ` [RFA/RFC] Add dump and load command to process record (file format etc) Michael Snyder
2009-08-06 2:17 ` Hui Zhu
2009-08-12 14:11 ` Michael Snyder
2009-08-12 15:16 ` Tom Tromey
2009-08-12 22:38 ` Michael Snyder
2009-08-16 0:04 ` Hui Zhu
2009-08-05 21:23 ` [RFA/RFC] Add dump and load command to process record and replay Michael Snyder
2009-08-06 3:14 ` Eli Zaretskii
2009-08-06 14:16 ` Hui Zhu
2009-08-07 3:27 ` Michael Snyder
2009-08-07 3:29 ` Hui Zhu
2009-08-07 3:34 ` Michael Snyder
2009-08-07 4:06 ` Hui Zhu
2009-08-07 8:41 ` Eli Zaretskii
2009-08-07 9:53 ` Hui Zhu
2009-08-07 12:51 ` Eli Zaretskii
2009-08-07 16:22 ` Hui Zhu
2009-08-07 17:42 ` Michael Snyder
2009-08-08 13:28 ` Hui Zhu
2009-08-10 3:09 ` Michael Snyder
2009-08-22 17:39 ` Hui Zhu
2009-08-23 1:14 ` Hui Zhu
2009-08-23 23:43 ` Michael Snyder [this message]
2009-08-24 8:20 ` Hui Zhu
2009-08-24 18:32 ` Michael Snyder
2009-08-25 8:47 ` Hui Zhu
2009-08-26 1:40 ` Michael Snyder
2009-08-26 2:59 ` Michael Snyder
2009-08-29 15:53 ` Hui Zhu
2009-08-29 18:06 ` Eli Zaretskii
2009-08-29 18:28 ` Hui Zhu
2009-08-29 20:26 ` Eli Zaretskii
2009-08-29 20:39 ` Michael Snyder
2009-08-30 3:03 ` Eli Zaretskii
2009-08-30 5:36 ` Hui Zhu
2009-08-30 23:40 ` Eli Zaretskii
2009-08-31 7:10 ` Hui Zhu
2009-09-05 3:30 ` Michael Snyder
2009-09-06 16:29 ` Hui Zhu
2009-08-29 20:05 ` Michael Snyder
2009-08-29 20:33 ` Eli Zaretskii
2009-08-29 21:20 ` Michael Snyder
2022-01-21 6:46 Simon Sobisch via Gdb-patches
2022-01-24 9:26 ` Hui Zhu via Gdb-patches
2022-04-13 12:21 ` Simon Sobisch via Gdb-patches
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=4A91CEEC.5000802@vmware.com \
--to=msnyder@vmware.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@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