From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15548 invoked by alias); 29 Mar 2013 16:28:05 -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 15516 invoked by uid 89); 29 Mar 2013 16:27:53 -0000 X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail-la0-f73.google.com (HELO mail-la0-f73.google.com) (209.85.215.73) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 29 Mar 2013 16:27:48 +0000 Received: by mail-la0-f73.google.com with SMTP id eb20so46007lab.2 for ; Fri, 29 Mar 2013 09:27:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:mime-version:content-type:content-transfer-encoding :message-id:date:to:cc:subject:in-reply-to:references:x-mailer :x-gm-message-state; bh=Q/R3jvaKgrgf+M9mjGVQsw1u9Xjz3qp3bwcyuRu46Ns=; b=GUvnMfv+/Ow4iEJLvnLML8aOl0kM7YJiZ4Lg5GOGkq/MtVUJ9dJ3PSjl+d/rQZFWsm E8M9D+Yx23MDX/tQfToWm1VEZFwcgLVxed2RK6aZ02sl+MQ3/MwkaK4/rNNBU0Ga9pIb g0Hrdlo+gmHc1zW1qEyx56/5XbxgyxlMvQGc3f++BYq4MaqGt+SZGCuNbYlG689PiK7O 5eis2aV9VtExB6oZnOtri3vPt+z4xI+tf3eOP8Ta1E+ygDUcxKsUk9kPYG1xCe2KGDMx /RFfh4drvRbZE7QNUabHzVK55Kl4y8mmjO5hX6uv9lz/wSJbPt74J/17gLij4513ULEn E4bQ== X-Received: by 10.15.90.206 with SMTP id q54mr4597536eez.2.1364574465996; Fri, 29 Mar 2013 09:27:45 -0700 (PDT) Received: from corp2gmr1-2.eem.corp.google.com (corp2gmr1-2.eem.corp.google.com [172.25.138.117]) by gmr-mx.google.com with ESMTPS id 6si825057eej.0.2013.03.29.09.27.45 (version=TLSv1.1 cipher=AES128-SHA bits=128/128); Fri, 29 Mar 2013 09:27:45 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.17.128.107]) by corp2gmr1-2.eem.corp.google.com (Postfix) with ESMTP id 7A3C91E404E; Fri, 29 Mar 2013 09:27:44 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20821.49407.164383.945535@ruffy2.mtv.corp.google.com> Date: Fri, 29 Mar 2013 17:56:00 -0000 To: Yao Qi Cc: Tom Tromey , gdb-patches Subject: Re: [PATCH v3 03/15] Read CTF by the ctf target In-Reply-To: <51514D75.3070402@codesourcery.com> References: <1362800844-27940-1-git-send-email-yao@codesourcery.com> <1362800844-27940-4-git-send-email-yao@codesourcery.com> <871ubjawq8.fsf@fleche.redhat.com> <20802.2886.914505.51784@ruffy2.mtv.corp.google.com> <51501E65.1020801@codesourcery.com> <20816.28886.574691.604457@ruffy2.mtv.corp.google.com> <51514D75.3070402@codesourcery.com> X-Gm-Message-State: ALoCoQm1deziK2Hu1WnEYXRuJ9a9XQ+uzCkslr5jRJwXIf9zuQQ8R4CQ+GQerVTONQxq8z/81AXd80XyHlVc+Mmmx9cgL9Ar44+jogPgwhoKnCTGORuNmopoy4m/ghVQiG4e0f3IYtl+zaA7xpwZCg6ZVZ9b4fKLzq5rCTtHsUaBdMz87IcNlO6o1wShDpKjZ2t9UznHclEGRkiqPXK8iHc3YgT2A2imJA== X-SW-Source: 2013-03/txt/msg01117.txt.bz2 Yao Qi writes: > 2013-03-26 Hui Zhu > Yao Qi > > * configure.ac: Check libbabeltrace is installed. > * config.in: Regenerate. > * configure: Regenerate. > * Makefile.in (LIBBABELTRACE): New. > (CLIBS): Add LIBBABELTRACE. > * ctf.c (ctx, ctf_iter, trace_dirname): New. > (ctf_destroy, ctf_open_dir, ctf_open): New. > (ctf_close, ctf_files_info): New. > (ctf_fetch_registers, ctf_xfer_partial): New. > (ctf_get_trace_state_variable_value): New. > (ctf_get_tpnum_from_frame_event): New. > (ctf_get_traceframe_address): New. > (ctf_trace_find, ctf_has_stack): New. > (ctf_has_registers, ctf_traceframe_info, init_ctf_ops): New. > (_initialize_ctf): New. > * tracepoint.c (get_tracepoint_number): New > (struct traceframe_info, trace_regblock_size): Move it to ... > * tracepoint.h: ... here. > (get_tracepoint_number): Declare it. > [...] > +/* Return the address at which the current frame was collected. */ > + > +static ULONGEST > +ctf_get_traceframe_address (void) > +{ > + struct bt_ctf_event *event = NULL; > + struct bt_iter_pos *pos; > + ULONGEST addr = 0; > + > + gdb_assert (ctf_iter != NULL); > + pos = bt_iter_get_pos (bt_ctf_get_iter (ctf_iter)); > + gdb_assert (pos->type == BT_SEEK_RESTORE); > + > + while (1) > + { > + const char *name; > + struct bt_ctf_event *event1; > + > + event1 = bt_ctf_iter_read_event (ctf_iter); > + > + name = bt_ctf_event_name (event1); > + > + if (name == NULL) > + break; > + else if (strcmp (name, "frame") == 0) > + { > + event = event1; > + break; > + } > + > + if (bt_iter_next (bt_ctf_get_iter (ctf_iter)) < 0) > + break; > + } > + > + if (event != NULL) > + { > + int tpnum = ctf_get_tpnum_from_frame_event (event); > + struct tracepoint *tp > + = get_tracepoint_by_number_on_target (tpnum); > + > + if (tp && tp->base.loc) > + addr = tp->base.loc->address; > + } > + > + /* Restore the position. */ > + bt_iter_set_pos (bt_ctf_get_iter (ctf_iter), pos); > + > + return addr; > +} One last thing. Apologies for not bringing this up earlier. I'm not sure we have any conventions explicitly saying to use CORE_ADDR instead of {,U}LONGEST for addresses, but tp->base.loc->address is a CORE_ADDR. It feels like everywhere you're using ULONGEST for addresses you need to use CORE_ADDR instead. Or maybe there's a specific reason to use ULONGEST?