From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27738 invoked by alias); 26 Jul 2019 00:13:04 -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 27730 invoked by uid 89); 26 Jul 2019 00:13:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=out X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Jul 2019 00:13:02 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x6Q08gMc149045; Fri, 26 Jul 2019 00:13:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=MTNUry9Vpouc5qHUWvF6fgYdUIewbUbVTa+fc+8VCNo=; b=L+zSML1ZIxniKQfVtP1J/nHmTPwJUn+vrAUdogcyQ9adw2Hp+kfePIMR38UTn1ne2632 7udp5ZKPc0uEfWd609ffcsb6UmhPMHyKN0sWMJyp40fERKntZTzLTB6+v3DKjTGa0RlM RfZLeX0bPM4uWTz7jHbORdnWNBzJdAtsDhgsyTJUjjRb/BEB34S53manP33RUAW2lxUR OAmczkGiAWm3zRY2H8434oyrREQ5ixVt+KpMITxgHR7LIFSvu9mDyEvwYXuN2kCiXaRQ 23Egwqd5ZHrTA/V+pcnQ/Fw1UYp6Yz6pmXP+ZY7qpXMILZpELrP6FhkY3YeqGC2tqICJ +A== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2tx61c74p1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Jul 2019 00:13:00 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x6Q07prq020433; Fri, 26 Jul 2019 00:13:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2tycv7b2tw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Jul 2019 00:13:00 +0000 Received: from abhmp0022.oracle.com (abhmp0022.oracle.com [141.146.116.28]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x6Q0CwwF031213; Fri, 26 Jul 2019 00:12:59 GMT Received: from [10.159.133.48] (/10.159.133.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jul 2019 17:12:58 -0700 Subject: Re: [PATCH] gdb: CTF support To: Tom Tromey Cc: gdb-patches@sourceware.org References: <1563926228-31569-1-git-send-email-weimin.pan@oracle.com> <87v9vrtde8.fsf@tromey.com> <87o91ithd9.fsf@tromey.com> From: Wei-min Pan Message-ID: <389644b2-5fb4-b963-f362-e9a2e34b44ac@oracle.com> Date: Fri, 26 Jul 2019 00:13:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87o91ithd9.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-07/txt/msg00564.txt.bz2 On 7/25/2019 5:42 AM, Tom Tromey wrote: >>>>> ">" == Wei-min Pan writes: > Tom> dependencies = { module=all-binutils; on=all-libctf; }; > > >> There are more libctf changes in both Makefile.def and Makefile.in. > >> Please see commit 0e65dfbaf3a0299e4837216a103c28625d4b4f1d which > >> should address your concern? > > That commit adds the dependency of binutils on libctf.  But, if gdb is > going to use libctf, then another one is needed for gdb. Otherwise, I > think nothing ensures that libctf will be built before gdb. If libctf were not built before gdb, gdb build would have failed which is not the case. Will take another look. > >>>> +#include > > Tom> Probably just "ctf.h" here?  The top-level include directory is already > Tom> on the include path. > > >> There is already a gdb/ctf.h for tracing? > > Aha, thanks for pointing that out.  In this case I think it would be > better to rename gdb/ctf.h to something else. While gdb/ctf.h is included in following files: tracefile.c tracepoint.c mi/mi-main.c it's only used in tracepoint.c. Will remove the include from tracefile.c and mi-main.c and rename it to "tracectf.h"? > Tom> There's a type-safe registry API now.  I would prefer that for new > Tom> code. > > >> Where can I get more info on this API? >  I thought I'd written a comment in registry.h, but I see I did not. > > The registry generates a template class named "TAG_key"; e.g. for the > objfile registry it is called objfile_key.  You create your registry key > using they type you plan to store.  So, from arm-tdep.c: > >     static objfile_key arm_objfile_data_key; > > If you use new/delete to manage the object that you store, then the > above is enough.  For the htab case, see elfread.c: > >     static const struct objfile_key >       elf_objfile_gnu_ifunc_cache_data; > > The key has several methods, like "get" (to get the object), and "set" > (to set the object).  If you're using plain new/delete, it will have an > "emplace" method that you can use to create a new object. Thanks for info. Will use the new API.