[commit/RFC] fix gdb.trace/collection.exp bitrot

[Stan Shebs]

Pedro Alves wrote:
> That is, the tracepoint was set to collect the `argarray' argument, of:
>
>  /* Test collecting args. */
>  int args_test_func (argc, argi, argf, argd, argstruct, argarray)
>       char   argc;
>       int    argi;
>       float  argf;
>       double argd;
>       test_struct argstruct;
>       int argarray[4];
>  {
>
> But, array passing in C is special; even though the argument is
> declared like an array, only a pointer to the array passed in.
>
> So, collecting `argarray' only collects the array address, not its
> contents.  But, the test tried to print the array's contents, and,
> that fails.
>
> The question is.  What to do then?  Should the test just be
> fixed to not assume that collecting an array argument, collects
> the whole array?  I believe so.
>   

My offhand guess is that the ABI is playing a role somehow, where 
sufficiently large arrays are being passed by reference, and the type 
info going into the collection is describing it as a pointer, rather 
than an array.

I don't have a good sense about what collection *should* do though.  For 
instance, in the case of structures, a field that is an array is 
collected in its entirety.  Now collection does that as a sort of 
accident of the implementation; an array in a struct occupies bytes M 
through N of the struct's value, and so it just happens to ride along 
with the rest of the struct's fields.  But conversely, when it comes to 
strings, collection doesn't try to guess at how many bytes of the string 
to collect, it just takes the pointer.

There are a couple user-friendliness reasons to collect all the array 
elements. One, it matches what the user sees in the source code - users 
don't want to have to guess at the implementation du jour, or worse, 
have to write different tracepoint actions depending on whether a 
#define for array size expands into 2 or 20.  Second, "collect $args" 
will work as expected, and not have to be written as "collect $args, 
argarray[0]@4" (which would be hard to get right if the 4 came from a 
macro).  Third, if collection collects a little more than is strictly 
necessary, then it improves the chances that trace frames will have the 
right data on the first try, instead of requiring a re-run.

My inclination for now is just to mark as known failures, so as not to 
get too bogged down.

Stan