From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24066 invoked by alias); 25 Jun 2013 16:01:14 -0000 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 Received: (qmail 24056 invoked by uid 89); 25 Jun 2013 16:01:14 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_VN autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 25 Jun 2013 16:01:13 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5PG1AZA006895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 12:01:11 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5PG19gW011658; Tue, 25 Jun 2013 12:01:10 -0400 Message-ID: <51C9BEC4.5070503@redhat.com> Date: Tue, 25 Jun 2013 16:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 4/6] Add id of TSV into traceframe_info. References: <1370610493-26468-1-git-send-email-yao@codesourcery.com> <1371086914-8398-1-git-send-email-yao@codesourcery.com> <1371086914-8398-5-git-send-email-yao@codesourcery.com> In-Reply-To: <1371086914-8398-5-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00722.txt.bz2 On 06/13/2013 02:28 AM, Yao Qi wrote: > diff --git a/gdb/ctf.c b/gdb/ctf.c > index 278f950..1f6402d 100644 > --- a/gdb/ctf.c > +++ b/gdb/ctf.c > @@ -1778,6 +1778,18 @@ ctf_traceframe_info (void) > def = bt_ctf_get_field (event, scope, "length"); > r->length = (uint16_t) bt_ctf_get_uint64 (def); > } > + else if (strcmp (name, "tsv") == 0) > + { > + int32_t vnum; > + const struct bt_definition *scope > + = bt_ctf_get_top_level_scope (event, > + BT_EVENT_FIELDS); > + const struct bt_definition *def; > + > + def = bt_ctf_get_field (event, scope, "num"); > + vnum = (int32_t) bt_ctf_get_uint64 (def); > + VEC_safe_push (int, info->tvars, vnum); The VEC holds "int", so this passing through int32_looks a little odd. And why uint64, if the id is always written as int32 ? Both are written as int32_t: ... /* number */ ctf_save_write_int32 (&writer->tcs, tsv->number); ... static void ctf_write_frame_v_block (struct trace_file_writer *self, int32_t num, uint64_t val) { ... /* num. */ ctf_save_align_write (&writer->tcs, (gdb_byte *) &num, 4, 4); ... BTW, this made me look at the ctf definitions, and I notice that: ctf_save_write_metadata (&writer->tcs, "\n"); ctf_save_write_metadata (&writer->tcs, "event {\n\tname = \"tsv_def\";\n" "\tid = %u;\n\tfields := struct { \n" "\t\tint64_t initial_value;\n" "\t\tint32_t number;\n" "\t\tint32_t builtin;\n" "\t\tchars name;\n" "\t};\n" "};\n", CTF_EVENT_ID_TSV_DEF); "number" here is int32_t, but here ctf_save_write_metadata (&writer->tcs, "\n"); ctf_save_write_metadata (&writer->tcs, "event {\n\tname = \"tsv\";\n\tid = %u;\n" "\tfields := struct { \n" "\t\tuint64_t val;\n" "\t\tuint32_t num;\n" "\t};\n" "};\n", CTF_EVENT_ID_TSV); "num" is uint32_t. Otherwise this is OK. Thanks, -- Pedro Alves