From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29241 invoked by alias); 1 Apr 2010 01:32:26 -0000 Received: (qmail 29210 invoked by uid 22791); 1 Apr 2010 01:32:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Apr 2010 01:32:19 +0000 Received: (qmail 13839 invoked from network); 1 Apr 2010 01:32:17 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Apr 2010 01:32:17 -0000 From: Pedro Alves To: Stan Shebs Subject: Re: [commit/RFC] fix gdb.trace/collection.exp bitrot Date: Thu, 01 Apr 2010 01:32:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201003290045.17238.pedro@codesourcery.com> <4BB3BF38.3020102@codesourcery.com> In-Reply-To: <4BB3BF38.3020102@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004010232.15304.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00001.txt.bz2 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: . 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 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"