This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [unavailable values part 1, 15/17] print pointers with 'set print object on'


On Thursday 10 February 2011 04:42:58, Joel Brobecker wrote:
> > +int
> > +value_entirely_available (struct value *value)
> > +{
> > +  if (value == NULL)
> > +    return 1;
> 
> Does it actually happen that we call this function with a NULL value?
> At first, I thought that we should "obviously" return 0, in this case,
> since nothing is available, but then again, thinking about it the other
> way it is equally "obvious" that no part of the given value is missing,
> and therefore the value is entirely available... Hum...

Ah, forgot that in.  I put that there early on, before fixing
all val_print & co. callers to pass in a value.  We used
to get NULL values here.  That was just like these two other
related functions in the tree today:

int
value_bits_valid (const struct value *value, int offset, int length)
{
  if (value == NULL || !value->optimized_out)
    return 1;
  if (value->lval != lval_computed
      || !value->location.computed.funcs->check_validity)
    return 0;
  return value->location.computed.funcs->check_validity (value, offset,
							 length);
}

and value_bits_synthetic_pointer too now.

If you look at the callers of these functions, it'll become
clear what the return when you are working with a NULL
value "should" be.  That is, if you didn't have a value to
work with (in val_print & co), you'd want to consider
the whole VALADDR buffer contents passed around to
be considered valid and available, and still print normally.
None of the callers was checking for NULL themselves,
supposedly, so that the hack was kept centralized (that
was my thinking).

We shouldn't need all these hacks anymore.  I've removed
it from the new value_entirely_available.  That
actually revealed a buglet in patch #9, were I was
supposed to support a NULL value but wasn't.  :-)
I'll post an updated version of that patch in a bit.

Meanwhile, I also tested removing the hack from
value_bits_valid and value_bits_synthetic_pointer and that
caused no crashes/regressions.

Thanks much for the review!

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]