Re: [unavailable values part 1, 01/17] base support for unavailable value contents

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 14 Feb 2011 13:59:11 +0100, Pedro Alves wrote:
> On Monday 14 February 2011 11:59:19, Jan Kratochvil wrote:
> > On Thu, 10 Feb 2011 20:30:26 +0100, Pedro Alves wrote:
> > > +static int
> > > +ranges_contain_p (VEC(range_s) *ranges, int offset, int length)
> > 
> > Couldn't even this function stick with the `overlap' term?
> 
> I guess it could.  There's already a ranges_overlap function
> though.  I'm open to concrete suggestions, though IMO this
> isn't worth the bother.

mem_ranges_list_overlaps?

Contrary to:
mem_ranges_overlap (CORE_ADDR start1, int len1, CORE_ADDR start2, int len2)


> If we switch the logic, we need to always allocate the VEC with a single
> range covering the whole contents, and then punch holes as we
> find them.  As that's more wasteful in terms of memory, I opted
> for the current logic.  Or maybe we could special case the empty
> case as meaning all-available?  It might work.

I agree but I do not consider this difference so important.


> > it would also enable storing discontiguous memory with
> > a value.
> 
> Can't see why you can't keep the "unavailable" ranges logic
> even if we store discontiguous memory in values.

It is questionable if it is the same.  I thought that any memory which is not
stored is <unavailable>.  Another look may be the memory is of three kinds:
 * stored/available
 * marked as <unavailable>
 * not stored, internal GDB error if an access is attempted

In the three-kinds model you are right these two features are unrelated.


Anyway your patchset is checked in and I do not plan to place much new
features on top of archer-jankratochvil-vla before it gets merged in some
form.


> I haven't looked at your code yet though.

archer-jankratochvil-vla currently does not contain any discontiguous memory
ranges code.  I mentioned it as it could benefit from such a feature.


Thanks,
Jan