From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10870 invoked by alias); 31 Mar 2010 21:31:49 -0000 Received: (qmail 10851 invoked by uid 22791); 31 Mar 2010 21:31:48 -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; Wed, 31 Mar 2010 21:31:43 +0000 Received: (qmail 29278 invoked from network); 31 Mar 2010 21:31:42 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Mar 2010 21:31:42 -0000 Message-ID: <4BB3BF38.3020102@codesourcery.com> Date: Wed, 31 Mar 2010 21:31:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org, Stan Shebs Subject: Re: [commit/RFC] fix gdb.trace/collection.exp bitrot References: <201003290045.17238.pedro@codesourcery.com> In-Reply-To: <201003290045.17238.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-03/txt/msg01122.txt.bz2 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