[unavailable values part 1, 00/17] introduction

[Pedro Alves <pedro@codesourcery.com>]

In the context of tracepoints, I've been working on
adding support for partial/incomplete objects.  That is, say, when 
printing an array where only a few elements have been collected,
print  what you can, and print something like "<unavailable>"
(like <optimized out>) for what has not been collected.  E.g., with:

struct foo {
  int a, b;
  int array[10000];
  void *ptr;
};

struct foo2 {
  int d, ef;
  struct foo foo;
};

struct foo2 foo2;

and a tracepoint that just collects "foo2.foo.array[0]",
when printing foo2 while inspecting the corresponding collected
traceframe, currently we get:

(gdb) p foo2
Cannot access memory at address 0x601080

This is GDB trying to read [&foo2, &foo2+sizeof foo2) for an lval_memory
value representing "foo2" and the read failing because required
memory is not "available" (it was not collected).

vs afterwards, after all the necessary changes, we'll get something like:

(gdb) p foo2
$1 = {d = <unavailable>, ef = <unavailable>, foo = {a = <unavailable>, b = 
<unavailable>, array = {12345678, 
      <unavailable> <repeats 9999 times>}, ptr = <unavailable>}}

That is, we will still print what is available.

This requires marking chunks of a value's contents buffer as "unavailable"
 at value read time, and, at value print time, check whether the value 
contents chunk being printed is "available".  The "unavailable"-ness of 
the contents needs to be part of the struct value itself, given that when 
printing a value from the value history, you still want to know what is 
or isn't available, without consulting the target (which may not 
exist anymore).  The "unavailable"-ness of the contents is independent
of the backend lval_type (and implementation) behind a given
struct value, as it describes a "run-time"-ish property of the
value.

This series implements the base unavailable-value support, and
glues it with memory-based objects.  Then, it fixes the printing
machinery to know how to print unavailable values in assorted
situations, and adds base tests.

Unavailable/uncollected function locals and arguments won't
be printing gracefully yet after this series, as 
the glue between unavailable register / frame / values will
only come in a follow up series.  After all that,
frame unwinding will also be taught to terminate gracefully
when not enough (stack/registers) data has been collected,
instead of printing errors, as currently.

I'd appreciate comments and extra eyeballs on all of this.
Pending objections, I'd like to commit this after a
reasonable wait.

I've regtested the series as a whole against current
mainline, and I saw no regressions.

-- 
Pedro Alves