From: Michael Snyder <msnyder@vmware.com>
To: Hui Zhu <teawater@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"drow@false.org" <drow@false.org>
Subject: Re: Seems like a bug in target_read_stack / dcache_xfer_memory?
Date: Mon, 19 Oct 2009 18:02:00 -0000 [thread overview]
Message-ID: <4ADCA837.3010808@vmware.com> (raw)
In-Reply-To: <daef60380910182146s88a3c23k6dfb01e1c876a844@mail.gmail.com>
Hui Zhu wrote:
> I just want talk to you about it.
>
> + if (target_read_memory (entry->u.mem.addr, mem, entry->u.mem.len))
> + {
> + entry->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,
> + record_get_loc (entry),
> + entry->u.mem.len))
>
> Maybe we need change it to:
> if (target_read_memory (entry->u.mem.addr, mem, entry->u.mem.len) <= 0)
> if (target_write_memory (entry->u.mem.addr,
> + record_get_loc (entry),
> + entry->u.mem.len) <= 0)
Yeah, I think you're right.
That warning used to be an error, so we wouldn't fall through,
but now we do.
However, this is not what causes my current problem.
I'll leave it up to you to find a fix for this one. ;-)
> On Mon, Oct 19, 2009 at 06:31, Michael Snyder <msnyder@vmware.com> wrote:
>> OK, this is right at the hairy edge of my understanding, and I
>> admit up front that I did not carefully follow the email thread, but...
>>
>> There was this email thread about reading beyond the stack, and
>> using dcache, which I did not follow carefully. And now I think
>> I'm running into it.
>>
>> Short version: code in memory_xfer_partial looks like this:
>>
>> 1280 /* FIXME drow/2006-08-09: If we're going to preserve const
>> 1281 correctness dcache_xfer_memory should take readbuf and
>> 1282 writebuf. */
>> 1283 res = dcache_xfer_memory (ops, target_dcache, memaddr,
>> 1284 (void *) writebuf,
>> 1285 reg_len, 1);
>> 1286 if (res <= 0)
>> 1287 return -1;
>>
>> I think that's wrong. I think it needs to test for "res == 0".
>>
>> Comment at dcache_xfer_memory says:
>>
>> The meaning of the result is the same as for target_write
>>
>> (Gripe: someone please fix that comment. Why should I have to
>> go find another function in another file to find out what this
>> function returns?)
>>
>> So the comment at target_write says... oh wait! There is no
>> comment at target_write! I'm afraid I'm going to have to start
>> getting grumpy now...
>>
>> Well, that returns target_write_with_progress. The comment
>> there makes no mention of the return value. But it returns
>> target_write_partial. STILL no comment about the return value.
>> But this returns target_xfer_partial. GUESS WHAT?
>>
>> Well, this returns memory_xfer_partial, which is right back
>> where I started. And *its* comment says:
>>
>> The arguments and return
>> value are just as for target_xfer_partial
>>
>> Ummm, come on guys. Its Sunday and I've had a long day.
>> Joke's getting old. Whoever took the comments, please put them back.
>>
>> Anyway, I don't even remember now how I figured this out, but
>> I *THINK* what all these guys return is either 0 for success,
>> or an errno value less than zoro.
>>
>> And if that's true, then line 1286 up there needs to bail out
>> on zero and let the other target stack methods have a chance
>> to read the memory.
>>
>> Eh?
>>
>> We now return you to the nice Michael. ;-)
>>
>> Daniel, you're not the target, you're only Cc:ed because your
>> name is in the one comment that I *did* find.
>>
>>
>>
prev parent reply other threads:[~2009-10-19 18:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-18 22:37 Michael Snyder
2009-10-18 22:51 ` drow
2009-10-19 17:49 ` Michael Snyder
2009-10-19 18:37 ` Daniel Jacobowitz
2009-10-19 19:41 ` Michael Snyder
2009-10-19 21:28 ` Daniel Jacobowitz
2009-10-19 21:42 ` Michael Snyder
2009-10-22 2:46 ` Doug Evans
2009-10-22 18:02 ` Michael Snyder
2009-10-22 20:01 ` Michael Snyder
2009-10-23 17:18 ` Doug Evans
2009-10-25 2:03 ` Michael Snyder
2009-10-26 8:25 ` Hui Zhu
2009-10-19 4:46 ` Hui Zhu
2009-10-19 18:02 ` Michael Snyder [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=4ADCA837.3010808@vmware.com \
--to=msnyder@vmware.com \
--cc=drow@false.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