From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Partially available/unavailable data in requested range
Date: Fri, 25 Apr 2014 10:23:00 -0000 [thread overview]
Message-ID: <535A3780.4010302@redhat.com> (raw)
In-Reply-To: <535A2169.7020905@codesourcery.com>
On 04/25/2014 09:48 AM, Yao Qi wrote:
> I thought of this when I wrote this patch. I was unable to figure
> out your trim-LEN-up trick, and get the code complicated. Given
> "requesting memory across sections" is a rare case, I didn't go on
> this track further.
Well...
On 04/25/2014 09:48 AM, Yao Qi wrote:
> On 04/25/2014 12:19 AM, Pedro Alves wrote:
>> first_addr_available is clearer than min_addr_available").
>
> I don't think "first" is clearer than "min". There are multiple 'M'
> blocks in a traceframe, and the address of some of them are within the
> desired range [OFFSET, OFFSET + LEN). We are looking for the minimal
> address within the range, instead of the first address within the range.
> For example, supposing we have three 'M' blocks, M1 (0x01 0x02),
> M2 (0x07, 0x08) and M3 (0x4, 0x05), and the requested range is
> [0x03, 0x09), the first 'M' block within this range is M2, while the
> minimal address of 'M' block is M3. M3 is what we are looking for.
It confused me, because I read "minimal" as in "only barely adequate".
And then we have "maddr", starting with "m", and "M" blocks. That's a
lot of unrelated 'm's. I can see now how "first" might be confusing
as well, as leading to think that it's the first we encounter. Maybe
"low" would be even better:
/* Records the lowest available address of all blocks that
intersects the requested range. */
ULONGEST low_addr_available = 0;
> In my patch, there is one more condition check
>
> if (offset < maddr && maddr < (offset + len))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> if (min_addr_available == 0 || min_addr_available > maddr)
> min_addr_available = maddr;
>
> to avoid recoding minimal address *outside* of requested range. For
> example, we have three 'M' blocks, M1 (0x01 0x02), M2 (0x07, 0x08) and
> M3 (0x04, 0x05), and the requested range is [0x03, 0x09).
>
> OFFSET
> |--- requested ---|
> |-M1-| |-M2-| |-M3-|
>
> The MIN_ADDR_AVAILABLE is expected to be 0x04 instead of 0x01.
Ah, indeed.
Thanks,
--
Pedro Alves
prev parent reply other threads:[~2014-04-25 10:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-20 12:50 Yao Qi
2014-04-24 16:19 ` Pedro Alves
2014-04-25 8:51 ` Yao Qi
2014-04-25 10:23 ` Pedro Alves [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=535A3780.4010302@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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