From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 800B13858C52 for ; Mon, 28 Nov 2022 22:29:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 800B13858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0e.wildebeest.org [172.31.17.144]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 304A1300B351; Mon, 28 Nov 2022 23:29:02 +0100 (CET) Received: by reform (Postfix, from userid 1000) id D50F02E80563; Mon, 28 Nov 2022 23:29:01 +0100 (CET) Date: Mon, 28 Nov 2022 23:29:01 +0100 From: Mark Wielaard To: Martin =?utf-8?B?TGnFoWth?= Cc: "Dmitry V. Levin" , elfutils-devel@sourceware.org, Fangrui Song Subject: Re: [PATCH][RFC] readelf: partial support of ZSTD compression Message-ID: References: <542eb279-d15d-6f17-02c0-c53fd0f33055@suse.cz> <20221024114137.GA19251@altlinux.org> <0375dd0c-2410-d1ca-8ce7-41293e8e2fa2@suse.cz> <20221024164806.GA21412@altlinux.org> <6c1ce1f1-2e45-20bb-e98d-6d35692addfb@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-3032.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Martin, On Mon, Nov 28, 2022 at 02:16:35PM +0100, Martin Liška wrote: > On 10/29/22 00:21, Mark Wielaard wrote: > > Although I like to also have compression working. Then we can also > > add support to src/elfcompress, which makes for a good testcase. See > > tests/run-compress.sh (which has found some subtle memory issues when > > run under valgrind). > > All right, so I'm preparing a full support for ZSTD (both compression and compression) > and I noticed a refactoring would be handy for compress_section function and callers > of the function. > > Note right now, there are basically 3 compression types and process_file > function handles basically all combinations of these (3 x 3 options), while adding ZSTD > support would make it even more complicated. However, ZSTD will behave very similar to ZLIB > (not zlib-gnu), except a different algorithm will be used. Plus, in order to distinguish > ZLIB from ZSTD, we need to read GElf_Chdr. > > So what do you think about the refactoring as the first step? Looks good. I would just add a sanity check that chdr.ch_type is of a known compression type (it is only checked to be not NONE atm). Cheers, Mark