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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 31 March 2010 22:31:36, Stan Shebs wrote:
> 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 think this depends on ABI.  AFAIK, arrays in C are always
passed to functions as pointers; you never get a copy of the
caller's array in the callee.  See:

 <http://c-faq.com/~scs/cclass/notes/sx10f.html>.

To do that (pass an array copy, for some reason), the trick is
usually to wrap the array in a struct.  One gets used to think
arrays and pointers are the same thing --- arrays do decay to
pointers as necessary, but they're not the same thing.

My guess is this is strictly debug info related.  Maybe the
compiler the test was written for described the "array"
argument really as an array.

> 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.  

To clear up confusion, in:

 void function (int array[4096], int opt)
 {
    ...
 }

The `4096' is mostly meaningless.  The real array size depends
on what the caller passed in at a particular invocation.  It is
valid for this function to be passed an array with less than
4096 elements, provided `function' doesn't access the missing
elements (e.g., depending on OPT).  Collection may fail if
GDB attempts to always collect 4096 (or N whatever).
The passed in array may be also more than 4096 elements wide,
and `function' may legally access the excess elements.
The `4096' is just useful as API documentation.

> 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).

( GDB supports macro expansion nowadays :-) )

> 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.

Yeah.  One of my worries is that convenience sometimes shoots
in the foot, as it may instead miscollect, or overcollect.
I guess that in a couple of years, when tracepoints get
more use, people will get used to these issues, and we'll
look back and wonder why was this even an issue --- it's
so obvious you need to specify the length!  or not!!

In any case, the only way GDB would be able to collect the
whole array, is for debug info to describe the `argarray[4]'
argument as an array instead of a pointer.   It doesn't on my
testing; it's always described as a pointer.  There's no way
for GDB to know the "array" size as written in the source
this way.

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

I've applied the below then.  I agree with xfailing,
because I'll be curious to see this xpass somewhere.

-- 
Pedro Alves
2010-04-01  Pedro Alves  <pedro@codesourcery.com>

	gdb/testsuite/
	* gdb.trace/collection.exp (gdb_collect_args_test)
	(gdb_collect_argarray_test): XFAIL the tests that assume the
	argarray argument's elements are collected.

---
 gdb/testsuite/gdb.trace/collection.exp |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Index: src/gdb/testsuite/gdb.trace/collection.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.trace/collection.exp	2010-04-01 01:26:37.000000000 +0100
+++ src/gdb/testsuite/gdb.trace/collection.exp	2010-04-01 01:43:58.000000000 +0100
@@ -166,15 +166,30 @@ proc gdb_collect_args_test { myargs msg 
 	    "collect $msg: collected arg struct member double"
 
     # array arg as one of several args (near end of list)
+
+    # It isn't clear why is the test assuming the array's elements are
+    # collected.  In C, an array as function parameters is a special
+    # case; it's just a pointer into the caller's array, and as such,
+    # that's what normally the debug info describes.  Maybe this was
+    # originaly written for a compiler where array parameters were
+    # really described as arrays in debug info.
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[0\]" \
 	    "\\$\[0-9\]+ = 111$cr" \
 	    "collect $msg: collected argarray #0"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[1\]" \
 	    "\\$\[0-9\]+ = 112$cr" \
 	    "collect $msg: collected argarray #1"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[2\]" \
 	    "\\$\[0-9\]+ = 113$cr" \
 	    "collect $msg: collected argarray #2"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[3\]" \
 	    "\\$\[0-9\]+ = 114$cr" \
 	    "collect $msg: collected argarray #3"
@@ -237,15 +252,30 @@ proc gdb_collect_argarray_test { myargs 
     run_trace_experiment $msg argarray_test_func
 
     # array arg as only argument
+
+    # It isn't clear why is the test assuming the array's elements are
+    # collected.  In C, an array as function parameters is a special
+    # case; it's just a pointer into the caller's array, and as such,
+    # that's what normally the debug info describes.  Maybe this was
+    # originaly written for a compiler where array parameters were
+    # really described as arrays in debug info.
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[0\]" \
 	    "\\$\[0-9\]+ = 111$cr" \
 	    "collect $msg: collected argarray #0"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[1\]" \
 	    "\\$\[0-9\]+ = 112$cr" \
 	    "collect $msg: collected argarray #1"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[2\]" \
 	    "\\$\[0-9\]+ = 113$cr" \
 	    "collect $msg: collected argarray #2"
+
+    setup_xfail "*-*-*"
     gdb_test "print argarray\[3\]" \
 	    "\\$\[0-9\]+ = 114$cr" \
 	    "collect $msg: collected argarray #3"