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: [commit/RFC] fix gdb.trace/collection.exp bitrot


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


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