From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id 4B82A3858C51 for ; Mon, 28 Mar 2022 16:23:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B82A3858C51 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy01.your-server.de ([78.46.139.224]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nYs9e-0009r1-BI; Mon, 28 Mar 2022 18:23:42 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYs9e-000Xew-8c; Mon, 28 Mar 2022 18:23:42 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EC14A4800B4; Mon, 28 Mar 2022 18:23:41 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5_JzwBO3Ab7o; Mon, 28 Mar 2022 18:23:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 8CFB64800FD; Mon, 28 Mar 2022 18:23:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ojKzG-Lcap3L; Mon, 28 Mar 2022 18:23:41 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 46F914800B4; Mon, 28 Mar 2022 18:23:41 +0200 (CEST) Message-ID: <9b3bc65d-be92-0a99-d5c3-c96b9fec881c@embedded-brains.de> Date: Mon, 28 Mar 2022 18:23:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] gcov-tool: Allow merging of empty profile lists Content-Language: en-US To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , gcc-patches@gcc.gnu.org References: <20220323093404.13225-1-sebastian.huber@embedded-brains.de> <0b4c9c67-0810-4521-2cca-522dbed52bb8@suse.cz> <76777016-d1d4-6e44-59f6-fbe3ff8249ac@embedded-brains.de> <930c7bec-aea5-9491-94cd-a4e8c86f9bfe@suse.cz> <262bfcbc-dfd7-722f-e06a-b7fb7dbbe977@embedded-brains.de> From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.5/26495/Mon Mar 28 10:19:21 2022) X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 16:23:46 -0000 On 24/03/2022 13:03, Martin Li=C5=A1ka wrote: > On 3/24/22 11:51, Sebastian Huber wrote: >> Maybe we could add the file path into the gcov information stream=20 >> using a=C2=A0new=C2=A0tag: >> >> #define=C2=A0GCOV_TAG_GCDA_FILE_NAME=C2=A0=C2=A0((gcov_unsigned_t)0xa5= 000000) >> >> Then the complete gcov information can be dumped using a single base64= =20 >> encoded stream. We could add some support to the gcov-tool to read=20 >> this stream=C2=A0and=C2=A0merge=C2=A0it=C2=A0into=C2=A0gcda=C2=A0files= . >=20 > I would support such patch! Ok, good. I work currently on a prototype implementation. My use case=20 would be like this. Run a test executable which dumps all gcov info objects in a serial data=20 stream. It could be encoded as base64. It could be also compressed. On=20 the host you unpack the encoded data stream and feed it into gcov-tool=20 using the new "merge-stream" subcommand: gcov-tool --help Usage: gcov-tool [OPTION]... SUB_COMMAND [OPTION]... Offline tool to handle gcda counts -h, --help Print this help, then exit -v, --version Print version number, then exit merge-stream [options] [stream-file] Merge coverage stream file (or=20 stdin) and coverage file contents -v, --verbose Verbose mode -w, --weight Set weights (float point values) Example: base64 -d log.txt | gcov-tool merge-stream The gcov-tool uses a new tag which contains the filename of the=20 associated gcov info file: gcov-dump b-xilinx_zynq_a9_qemu/init.gcda b-xilinx_zynq_a9_qemu/init.gcda:data:magic `gcda':version `B20 ' b-xilinx_zynq_a9_qemu/init.gcda:stamp 3496756572 b-xilinx_zynq_a9_qemu/init.gcda:checksum 137326246 b-xilinx_zynq_a9_qemu/init.gcda: a5000000: 62:FILENAME=20 `/home/EB/sebastian_h/src/lwip/b-xilinx_zynq_a9_qemu/init.gcda' b-xilinx_zynq_a9_qemu/init.gcda: a1000000: 8:OBJECT_SUMMARY runs=3D0,=20 sum_max=3D0 b-xilinx_zynq_a9_qemu/init.gcda: 01000000: 12:FUNCTION=20 ident=3D1016818396, lineno_checksum=3D0xd31791e7, cfg_checksum=3D0x452978= 9a b-xilinx_zynq_a9_qemu/init.gcda: 01a10000: 232:COUNTERS arcs 29 counts Should I generate this filename tag to all configurations or just in=20 case inhibit_libc is defined? Advantage: * No dependency on the GCC configuration Disadvantages: * Bigger files * Actual filename and the filename of the tag differ if file is moved * Potential information leak In any case, I would add the support for the (optional) filename tag to=20 all readers. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/