From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BA8093858001 for ; Mon, 4 Jan 2021 05:04:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BA8093858001 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 104545CF010332 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Jan 2021 00:04:10 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 104545CF010332 Received: from [10.0.0.213] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1D2A41E99A; Mon, 4 Jan 2021 00:04:05 -0500 (EST) Cc: doko@debian.org From: Simon Marchi Subject: Considering removing CTF (Common Trace Format) support in GDB To: "gdb@sourceware.org" Message-ID: <3fb1fbb6-836a-0e39-73a9-ef721630da88@polymtl.ca> Date: Mon, 4 Jan 2021 00:04:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 4 Jan 2021 05:04:05 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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: Mon, 04 Jan 2021 05:04:17 -0000 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. Simon [1] https://diamon.org/ctf/ [2] https://babeltrace.org/ [3] https://sourceware.org/bugzilla/show_bug.cgi?id=27142