From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacsray@gmail.com>
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176])
	by sourceware.org (Postfix) with ESMTPS id 88BE4385828D
	for <binutils@sourceware.org>; Tue,  4 Oct 2022 22:01:36 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88BE4385828D
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-pl1-f176.google.com with SMTP id f23so13813709plr.6
        for <binutils@sourceware.org>; Tue, 04 Oct 2022 15:01:36 -0700 (PDT)
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=R+HAF8qNWMEvmmvdW69a8kh5HWLrHEP/2P+FKIz3Rpg=;
        b=NbvXvksJYIjXkeBymd8W18Wf8X2yCojTr9V1NYWLrYElSQ14KQj+VpCAZCCEML/WKm
         uPLADLrNrc4kwYBGMQJVfznDhhs6n98lDRTv0QrV7LW4xZLDOKTrEosqS++Xu760zIoI
         hRmGKujm0aoE7qr2jqY5ohaoQllwMeAXIyNgS2Ppy5ODFf6QnXCbZcGX2J2KOEzfw5L7
         +5veVjC2IHb7uzAvBtWCiiU/hDGI97EuRFiAwA0qWeG4yKKGVTUHwQ7/pmSej/9YyzAB
         dxNtCD5zdz/osWgRz35CljvcD7kYDT9heVx5SMxMS8kFUWMdJd+0tCr3SKk13azBFPwe
         DFiA==
X-Gm-Message-State: ACrzQf3aoneDLMP/FNxC4E7uX5RwHBsBqFWXkZCFPpHtY2BqtlBuMKfT
	ptFRAkPPeMc9JYOT/VhTnCTp/JAaHd8=
X-Google-Smtp-Source: AMsMyM4qB9mJmJ5VikOonTG3B8A5ZdevvBCRwfpn1pN61jcO8fK2+xfCweNk749ELHdMtBJMSxgaAg==
X-Received: by 2002:a17:90b:1801:b0:202:7cf6:9f93 with SMTP id lw1-20020a17090b180100b002027cf69f93mr1737742pjb.170.1664920895452;
        Tue, 04 Oct 2022 15:01:35 -0700 (PDT)
Received: from localhost ([2620:15c:2d1:206:3b44:8be6:2478:e141])
        by smtp.gmail.com with ESMTPSA id 19-20020a621913000000b00561d79f1064sm1541281pfz.57.2022.10.04.15.01.34
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 04 Oct 2022 15:01:35 -0700 (PDT)
Date: Tue, 4 Oct 2022 15:01:34 -0700
From: Fangrui Song <i@maskray.me>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: Support objcopy changing compression to or from zstd
Message-ID: <20221004220134.ifx4i33v2obhzitr@gmail.com>
References: <YzvrMEdkXjIn5Lfz@squeak.grove.modra.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <YzvrMEdkXjIn5Lfz@squeak.grove.modra.org>
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: <binutils.sourceware.org>

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.