From: Pedro Alves <palves@redhat.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] btrace, vdso: add vdso target sections
Date: Mon, 19 May 2014 21:41:00 -0000 [thread overview]
Message-ID: <537A7A80.3050801@redhat.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B230C16E5C6@IRSMSX104.ger.corp.intel.com>
On 05/19/2014 12:30 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Metzger, Markus T
>> Sent: Monday, May 19, 2014 10:06 AM
>
>
>>>> +# trace the test code
>>>> +gdb_test_no_output "record btrace"
>>>> +gdb_test "next"
>>>
>>> Please add a pattern that makes sure the "next" actually
>>> finished successfully.
>
> There's another problem that showed when I added such a
> pattern for the "reverse-stepi" command.
>
> The command prints "Cannot access memory at address 0x4004b0".
> The error occurs during frame unwind when we try to
> disassemble an instruction in order to get its length.
>
> The problem is that the GDB memory cache may turn reads from
> one section into reads from a different section or from memory
> regions outside of any section.
>
> The address, 0x4004b0 is the first entry in .plt, a read-only code
> section. The disassembler tries to read 1 byte from this address.
> The memory cache turns this into a request for 64 bytes from
> 0x400480, which lies in a different section, .rela.plt in my case.
>
> The read still succeeds in my example since the other section is
> also readonly, but there's no guarantee for this.
>
> The memory read passes through record_btrace_xfer_partial
> which reduces the length to fit into a single section, so the target's
> read memory function tries to read the remainder of the cache line.
I got a bit confused by the above sentence. You must mean, a
function in target.c (target_read, etc.), not the target's
read memory function.
> This eventually fails since the cache line contains a memory region
> that is not contained in any section and record_btrace_xfer_partial
> returns TARGET_XFER_UNAVAILABLE.
> I would argue that the memory cache should not extend the original
> read request beyond section boundaries. What do you think?
Even in absence of section information, the cache should still be able to
handle the case of the target returning TARGET_XFER_UNAVAILABLE or
TARGET_XFER_E_IO or any error for memory that is outside the region
that the original caller of the memory read routine asked for.
Looks like that fallback is missing.
Does this patch fix it ?
---
gdb/dcache.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gdb/dcache.c b/gdb/dcache.c
index d3b546b..e75f583 100644
--- a/gdb/dcache.c
+++ b/gdb/dcache.c
@@ -497,8 +497,11 @@ dcache_read_memory_partial (struct target_ops *ops, DCACHE *dcache,
if (i == 0)
{
- /* FIXME: We lose the real error status. */
- return TARGET_XFER_E_IO;
+ /* Even though reading the whole line failed, we may be able to
+ read a piece starting where the caller wanted. */
+ return ops->to_xfer_partial (ops, TARGET_OBJECT_RAW_MEMORY, NULL,
+ myaddr, NULL, memaddr, len,
+ xfered_len);
}
else
{
next prev parent reply other threads:[~2014-05-19 21:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 8:53 Markus Metzger
2014-04-22 14:32 ` Metzger, Markus T
2014-04-22 14:39 ` Pedro Alves
2014-05-16 13:12 ` Pedro Alves
2014-05-19 8:07 ` Metzger, Markus T
2014-05-19 11:30 ` Metzger, Markus T
2014-05-19 21:41 ` Pedro Alves [this message]
2014-05-20 6:40 ` Metzger, Markus T
2014-05-20 11:12 ` Pedro Alves
2014-05-20 11:16 ` Metzger, Markus T
2014-05-20 17:15 ` [PATCH] Make the dcache (code/stack cache) handle line reading errors better Pedro Alves
[not found] ` <A78C989F6D9628469189715575E55B230C16FA4E@IRSMSX104.ger.corp.intel.com>
2014-05-21 9:45 ` [PATCH v2] " Pedro Alves
2014-05-21 11:29 ` Metzger, Markus T
2014-05-19 17:22 ` [PATCH] btrace, vdso: add vdso target sections Pedro Alves
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=537A7A80.3050801@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.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