From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28114 invoked by alias); 15 Jun 2010 22:51:57 -0000 Received: (qmail 28101 invoked by uid 22791); 15 Jun 2010 22:51:54 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Jun 2010 22:51:44 +0000 Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5FMpfKG012100 for ; Tue, 15 Jun 2010 15:51:41 -0700 Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by hpaq6.eem.corp.google.com with ESMTP id o5FMpC8K031556 for ; Tue, 15 Jun 2010 15:51:40 -0700 Received: by vws9 with SMTP id 9so7303234vws.31 for ; Tue, 15 Jun 2010 15:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.126.131 with SMTP id c3mr4242721vcs.48.1276642299864; Tue, 15 Jun 2010 15:51:39 -0700 (PDT) Received: by 10.220.189.201 with HTTP; Tue, 15 Jun 2010 15:51:39 -0700 (PDT) In-Reply-To: <4C0983C3.6000604@codesourcery.com> References: <4C0983C3.6000604@codesourcery.com> Date: Tue, 15 Jun 2010 22:51:00 -0000 Message-ID: Subject: Re: [RFC] Collecting strings at tracepoints From: Doug Evans To: Stan Shebs Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00051.txt.bz2 On Fri, Jun 4, 2010 at 3:52 PM, Stan Shebs wrote: > Collection of strings is a problem for tracepoint users, because the lite= ral > interpretation of "collect str", where str is a char *, is to collect the > address of the string, but not any of its contents. =A0It is possible to = use > the '@' syntax to get some contents, for instance "collect str@40" acquir= es > the first 40 characters, but it is a poor approximation; if the string is > shorter than that, you collect more than necessary, and possibly run into > access trouble if str+40 is outside the program's address space, or else = the > string is longer, in which case you may miss the part you really wanted. > > For normal printing of strings GDB has a couple tricks it does. =A0First,= it > explicitly recognizes types that are pointers to chars, and automatically > dereferences and prints the bytes it finds. =A0Second, the print elements > limit prevents excessive output in case the string is long. > > For tracepoint collection, I think the automatic heuristic is probably no= t a > good idea. =A0In interactive use, if you print too much string, or just w= anted > to see the address, there's no harm in displaying extra data. =A0But for > tracing, the user needs a little more control, so that the buffer doesn't > inadvertantly fill up too soon. =A0So I think that means that we should h= ave > the user explicitly request collection of string contents. > > Looking at how '@' syntax works, we can extend it without disrupting > expression parsing much. =A0For instance, "str@@" could mean to deference= str, > and collect bytes until a 0 is seen, or the print elements limit is reach= ed > (implication is that we would have to tell the target that number). =A0The > user could exercise even finer control by supplying the limit explicitly, > for instance "str@/80" to collect at most 80 chars of the string. > =A0("str@@80" seems like it would cause ambiguity problems vs "str@@"). > > This extended syntax could work for the print command too, in lieu of > tweaking the print element limit, and for types that GDB does not recogni= ze > as a string type. Apologies for coming into this a bit late. I want to make sure I understand the proposed syntax. str@@ would collect up to the first \0 or print elements limit. str@/80 would collect up to the first \0 or 80 bytes. That feels too inconsistent: "@@" triggers the special "up until the first \0", *except* when its @/. "up until the first \0" is one thing and specifying a limit is an add-on. Each should have their own syntax (e.g. str@@/80; it's perhaps klunkier, but @@ is klunky to begin with. :-)] Michael mentioned collect /s as a possibility. That *feels* better, given that you mention the print command (if p/s doesn't print its arg as a string, what does p/s mean?). To add a max-length, "collect /80s" doesn't work, it's inconsistent with the "x" command; "x /80s" doesn't mean "max 80 chars". Maybe "collect /s@80"? [At this point, I don't have a strong opinion on @ vs another character.] "x/s@80 foo" feels like a nice extension (print foo as a string up to 80 ch= ars) Plus "x/20s@80 foo" also works (print 20 strings beginning at foo, each with a max length of 80).