From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id B490B395C83D for ; Thu, 7 Jan 2021 12:00:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B490B395C83D Received: by mail-qk1-x733.google.com with SMTP id 186so5199120qkj.3 for ; Thu, 07 Jan 2021 04:00:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FJURjkc4SodJpYZeJZ4DmdmLMZuxE07NQoZf5+B7uHY=; b=gEqPJ3K0qV0717+pP2uEoo3z9r+nvxIx1yzJcDD45SlGCrFwr6NOPOQoZv0bWus6bD 3ezuOhWDekv/upuhXmObJs3wYwz+EQGO8upNsNnLRW5PbzxbjcEf6LZY0UobzfnXk2vr eXaUCG0HkfIDFv5U5vDMYGFfm4kYGzKYGSmMYUnAIC3hOJ9wnDAhkhk8RBDw/ITRtx3Q CHg/uYfuSEKd1bryfEkDvc23onfgLbtmLHR4jUCWjCx+4v8cxGAZ/Q140Tlnypyv6yIK RV/F5sAlTFUgCiVciNFAFg+sDqeJbgnSS/2eAtdP7UBqm75/vAKux25c72uRCxpMe0QT I3aw== X-Gm-Message-State: AOAM533sIIFyydX3Tp9tMTOOpYsJ3N5/qn0QP6yfqfMBQVZ/rsZw4C6g QCGZI0QrQsK8tr238bKffzWqqg== X-Google-Smtp-Source: ABdhPJx+eZfAOetNiWiSxb0lTaB1OW8vBUFj+XimWYEFQo0db/uJ5w84z6jBS0RdQDRqjLhroaV4GA== X-Received: by 2002:ae9:c013:: with SMTP id u19mr8629275qkk.59.1610020828283; Thu, 07 Jan 2021 04:00:28 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:7445:e9c5:57a:7bf5:361f? ([2804:7f0:8284:7445:e9c5:57a:7bf5:361f]) by smtp.gmail.com with ESMTPSA id c20sm2590487qtj.29.2021.01.07.04.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 04:00:27 -0800 (PST) Subject: Re: Considering removing CTF (Common Trace Format) support in GDB To: Simon Marchi , "gdb@sourceware.org" Cc: doko@debian.org References: <3fb1fbb6-836a-0e39-73a9-ef721630da88@polymtl.ca> From: Luis Machado Message-ID: <284c80fe-7810-af34-497a-db0d6efc324c@linaro.org> Date: Thu, 7 Jan 2021 09:00:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3fb1fbb6-836a-0e39-73a9-ef721630da88@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 12:00:30 -0000 On 1/4/21 2:04 AM, Simon Marchi via Gdb wrote: > Hi, > > GDB has support for saving tracepoint data in CTF [1]. Writing the CTF trace > is done by hand, but reading back the trace is done using Babeltrace [2] > version 1. Babeltrace 1 is considered deprecated since the release of > Babeltrace 2, which is a complete re-write, with a complete clean/stable API > and everything. > > Matthias (in CC) asked [3] if we could please migrate to Babeltrace 2, which > would be the logical thing to do. However, I think we must first decide > whether we want to keep support for exporting tracepoint data as CTF. > Tracepoints is already a not so widely used feature of GDB, and saving as CTF > is a niche use-case within that. > > My personal opinion is (disclaimer: I work for EfficiOS, the company behind the > Babeltrace project): as much as I would like to see Babeltrace 2 being used > more, I don't think the CTF support in GDB, as it is today, makes sense. The > original reason (AFAIU) to have GDB output CTF was to make it easier to process > / analyze traces created by GDB in other tools. However, the particular CTF > layout emitted by GDB is... strange. > > It looks like so (as decoded by `babeltrace2`): > > ... > frame: { tpnum = 2 }, { } > register: { tpnum = 2 }, { contents = "" } > memory: { tpnum = 2 }, { address = 0x40402C, length = 4, contents = [ [0] = 0, [1] = 0, [2] = 0, [3] = 0 ] } > memory: { tpnum = 2 }, { address = 0x7FFFFFFFDECC, length = 4, contents = [ [0] = 0, [1] = 0, [2] = 0, [3] = 0 ] } > frame: { tpnum = 2 }, { } > register: { tpnum = 2 }, { contents = "\x01" } > memory: { tpnum = 2 }, { address = 0x40402C, length = 4, contents = [ [0] = 1, [1] = 0, [2] = 0, [3] = 0 ] } > memory: { tpnum = 2 }, { address = 0x7FFFFFFFDECC, length = 4, contents = [ [0] = 1, [1] = 0, [2] = 0, [3] = 0 ] } > ... > > where each line is one "event". The intent of CTF is that one "event" contains > all the data collected when crossing one tracepoint. Here, the data collected > when crossing a tracepoint is layed out in 4 (and it could be more) events. I > don't know of any tool other than GDB that would make sense out of this. > > So if CTF support doesn't help in sharing the data with other tools, then it > just becomes an alternative format to GDB's own format for saving/loading trace > data. And I don't think it's particularly useful to have two formats for this. I agree. If the new version covers all use cases that the old did, then it sound best to move to version 2 and drop version 1. I take it this means the tracepoint machinery in GDB is still being used for some purpose?