Re: [PATCH] Partially available/unavailable data in requested range

Pedro Alves
2014-04-25T10:23:02Z

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