This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [unavailable values part 1, 01/17] base support for unavailable value contents
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