From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 5DE5D3858CDB for ; Wed, 5 Oct 2022 21:04:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DE5D3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x433.google.com with SMTP id y8so26607pfp.13 for ; Wed, 05 Oct 2022 14:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=MbKbpCMgEPXM/jw632NQI8hgObX6C8CsWtxQAdfhBPM=; b=S7t1GHy7IRxRfCk/RBBeW2qIQBkIyLwpYIJyAU4A9pGLQL3JPCmGYTvQbBiVhEqHwg Ee/vZn8qxGxcxRqVELKjcNDztkgGtB8fevdpQbR+clwI0gTCOZRkwg/aRC9qKTcc/zUk RdOYbQMf0OeZDgHBpOmubLp+IksBDVW5Xp6wuw4+nb342NJFSvAOJ3tWlVN7XDrZWOde UXSa8vSG2Lm1rDUob/DPyGlX7lVn17bcohgGMa60kLfKo97hv1R/LLhm/LDLB7qqiV6C 7ORQZ0JkqAj6e9FsXlaTiEqY28dyGBdHK3GWUbNoA4xodt1O7SbztbQ4fNsnVuSRupFz pCag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=MbKbpCMgEPXM/jw632NQI8hgObX6C8CsWtxQAdfhBPM=; b=BcOnMxeeeHxex/C90ZGmbVCaelpk44Uf9rZrlbaPWjEEsUizdjiAaIGtXZCQoOzxrV hEdlXU8fGyctt0mcPqTnB8yPueK8uSrWW/T8X23JlLLuzFPv4WpfGDhHSllbRuCsIQyE D0xfCulzPZG0nVYAIwlRtXHNpX5EVQ/esh5gOJbtZUwtWxQzBke4LqKen1R6jLApnT5d 5maWhhmAPk1aoGDcnvc2VvjS0t5KfbQ3LQodMFztDcH8iQ3pRaGgwKkWZHyNV2dN5o/n 5SmzrxDIatNFx8HsfutTGHrQjU41ZV0dVRQt/23KitLytlgxOm1e6tuGKJNm/PE0F8D5 fOVg== X-Gm-Message-State: ACrzQf0s08tIoUBJajMpnmNdI/ue4R4ePqozynzQ2ME+6rCtTZQhFMOq yExWymtJybEgvN1y4vtSo8mkdywV8PA= X-Google-Smtp-Source: AMsMyM7WDzciqzG39JE+smsgjcOyAUrLGPoBaBmA7nWSeCCRxtv2NMhdT2hyW+Dtk2iLlhEn13T/PQ== X-Received: by 2002:a65:4107:0:b0:439:54e1:8093 with SMTP id w7-20020a654107000000b0043954e18093mr1469021pgp.42.1665003861332; Wed, 05 Oct 2022 14:04:21 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id q2-20020a170902dac200b0017f6c7b51edsm4232576plx.194.2022.10.05.14.04.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 14:04:19 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 5AC3411405D1; Thu, 6 Oct 2022 07:34:16 +1030 (ACDT) Date: Thu, 6 Oct 2022 07:34:16 +1030 From: Alan Modra To: Fangrui Song Cc: binutils@sourceware.org Subject: Re: Support objcopy changing compression to or from zstd Message-ID: References: <20221004220134.ifx4i33v2obhzitr@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221004220134.ifx4i33v2obhzitr@gmail.com> X-Spam-Status: No, score=-3030.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Oct 04, 2022 at 03:01:34PM -0700, Fangrui Song wrote: > On 2022-10-04, Alan Modra via Binutils wrote: > > Commit 2cac01e3ffff lacked support for objcopy changing compression > > style. Add that support, which meant a rewrite of > > bfd_compress_section_contents. In the process I've fixed some memory > > leaks. > > For objcopy --compress-debug-sections=zstd , I know that omitting > recompression of zlib into zstd was intentional. > > --compress-debug-sections=zstd does not specify what to do when a section is > compressed, so both (a) > do nothing (b) re-compression with zstd are fine but I think > avoiding recompression can avoid some complexity... > > If a .o is compressed with zlib level 5, should --compress-debug-sections=zlib > re-compress it or leave it as-is? > > At any rate, I think the objcopy --compress-debug-sections=zstd > behavior with zlib compressed sections is mostly not interesting to a > user. I could have lived with objcopy --compress-debug-sections=zstd doing nothing on already compressed sections. After all, users could change compression schemes by a two step process, first objcopy --decompress-debug-sections then compress with the desired scheme. However, I discovered that objcopy --compress-debug-sections=zstd on a zlib-gnu compressed file copied the zlib data and tacked on a header specifying zstd. Which of course then causes errors on attempted decompression. That needed fixing regardless of what anyone thinks objcopy --compress-debug-sections=zstd should do with already compressed debug sections. -- Alan Modra Australia Development Lab, IBM