From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5532 invoked by alias); 6 Dec 2012 13:37:04 -0000 Received: (qmail 5352 invoked by uid 22791); 6 Dec 2012 13:37:01 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-bk0-f41.google.com (HELO mail-bk0-f41.google.com) (209.85.214.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Dec 2012 13:36:53 +0000 Received: by mail-bk0-f41.google.com with SMTP id jg9so2937005bkc.0 for ; Thu, 06 Dec 2012 05:36:52 -0800 (PST) Received: by 10.204.12.220 with SMTP id y28mr627443bky.112.1354801011961; Thu, 06 Dec 2012 05:36:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.32.12 with HTTP; Thu, 6 Dec 2012 05:36:11 -0800 (PST) In-Reply-To: <87pq2w3znr.fsf@fleche.redhat.com> References: <50AC323F.1070907@mentor.com> <87pq2w3znr.fsf@fleche.redhat.com> From: Hui Zhu Date: Thu, 06 Dec 2012 13:37:00 -0000 Message-ID: Subject: Re: [PATCH] Add CTF support to GDB [3/4] ctf target To: Tom Tromey Cc: Hui Zhu , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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: 2012-12/txt/msg00108.txt.bz2 On Fri, Nov 30, 2012 at 4:46 AM, Tom Tromey wrote: >>>>>> "Hui" == Hui Zhu writes: > > Hui> It add a new target ctf like the tfile target to read the ctf file. > Hui> After use this target open the ctf dir, you can use tfind to select > Hui> the ctf event. Each field inside this event will add to GDB as a > Hui> internalvar. And tdump will show all of them. And you can use python > Hui> read the value of them. > > Can you explain the internalvar feature a little? Why is it needed? > How are these variables named? What do they represent? Are they > different from the saved trace data somehow? I notice this feature > isn't in the documentation at all -- I think that is required, perhaps > with an example. > > Tom Actually, I am not sure internalvar is the right name of the $xxx var. About why is it needed? This is a very good question. Because CTF format is different with the tfile format and target ctf is different with other target. AFAIK each tracepoint frame entry in tfile format save the value of var in address len format. Then when GDB want read the value of a var, it will send address len info to "target tfile". But CTF is different, it save the value of each var without address. Libbabeltrace can parse this value out according to metadata file in the CTF format dir. Its advantage is to read this value don't need the debug info. But its weakness is not really fit with the GDB interace. My first design is just support tfind to select the traceframe and tdump to show all the value of the vars. But it is not very useful and cannot work very well with python. So I change it to add each value to the GDB as a internalvar and named as the name of var. The python can access each var in the CTF for example: python print int(gdb.parse_and_eval("$ret")) I will update the doc of "target ctf" to add some example about use this internalvar. Thanks, Hui