From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by sourceware.org (Postfix) with ESMTPS id 2A0703858D32 for ; Mon, 27 Feb 2023 13:44:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A0703858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f52.google.com with SMTP id r19-20020a05600c459300b003eb3e2a5e7bso2217452wmo.0 for ; Mon, 27 Feb 2023 05:44:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Dcav2c+t5X+CCVC56nuPRIyDJdqxoBkjKAZgR5HRBss=; b=D7HQiLqmZW/FZ09hOCrLq5kL3wbIgwK6fK6+xZuScAXIUFRPyCQ5L+HoiRJzUfv3Wo 2DVd6ePGDKTjvWn/cMW4Rp8hsBl0Xjvz9hvHxmuMMiJ6q03EMyDYwUDPy7L+cXlP8oJU 6J+dMK/Gu07SLKanteS32ymeyCUvUBBs9/WP9//0WnZ5bkeffzyhzB6jVk6OAAj/ppRq 9IL0+Ce6l4kgoZiyMg1FTFKvX2DEzRDbP3+OKQ8WgYIeSbowczbsvQy4IUBeauFQEzIE g5RPAk218ApdCwNOOEoYnbuM3jbSKFMZ6kW93UWcJUqb8Mdq8PZg1eV6uTHgn+qk1QZg KhQw== X-Gm-Message-State: AO0yUKWYPFffmlNV/yD5W6u6sbNrkrcBCoKNahBVQqZ26285gY9Pgp0U z+qPkHMp6IUmuXtOmx4P2lt1kMv8ct1QXQ== X-Google-Smtp-Source: AK7set9FECeWOZpHMJUzXoeUaZlqGu7fdVj+oHMH7YB71yHN8RtWNdctGOCWtW9rhZBLLN7ghV0LXw== X-Received: by 2002:a05:600c:3147:b0:3eb:3998:36f7 with SMTP id h7-20020a05600c314700b003eb399836f7mr4230299wmo.8.1677505496824; Mon, 27 Feb 2023 05:44:56 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id be6-20020a05600c1e8600b003e89e3284fasm13115558wmb.36.2023.02.27.05.44.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Feb 2023 05:44:56 -0800 (PST) Subject: Re: [PATCH] gas: Add --force-compress-debug-sections To: Jan Beulich , Tom de Vries Cc: binutils@sourceware.org, Michael Matz , Nick Clifton , Alan Modra References: <20230223124519.4228-1-tdevries@suse.de> <7dcb7bfb-f65d-aed8-78d4-944211ef5127@suse.de> <819f729a-da9c-3b8a-3769-7995c009704b@suse.com> <14a2defc-5371-84bc-2d59-9980755b112a@suse.de> <02dcf47c-4256-c5e5-de9e-814b60da8ce8@suse.com> <7cb226d0-1a91-9bad-181c-46f79c4d6eaf@suse.de> <0c60eef7-c612-ec37-8c3f-36b746ff8d95@suse.de> <711d9da5-8f31-3f1e-530b-5ae01780fcad@suse.de> From: Pedro Alves Message-ID: <70ee7e78-080f-ddce-9916-608bd8733e66@palves.net> Date: Mon, 27 Feb 2023 13:44:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,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: On 2023-02-27 9:03 a.m., Jan Beulich via Binutils wrote: > On 24.02.2023 15:57, Tom de Vries wrote: >> >> Is this more how you want it? > > I have to admit that I'm still puzzled by the presence of > finalize_parse_compress_debug_optarg() as well as you needing both a new > static variable and a new global one. But I guess whether that's really > needed first of all depends on the semantics we want e.g. > > --nocompress-debug-sections --compress-debug-sections=force > > to have (which, with how you have it presently, could also be expressed > as > > --compress-debug-sections=none+force > > or > > --compress-debug-sections=none --compress-debug-sections=force > > afaict). I view the present meaning as one sensible one, but I could > also see "none" (or equivalent) simply zapping the compression type > (and hence rendering "force" meaningless) as another sensible one. A > change in meaning may then also result in the three option combinations > above possibly not all doing the same. ISTM that these confusions (which no doubt users will have too) would go away if we did not try to put orthogonal settings into one option. Witness how the implementation uses two different enums: This new one: +enum compress_debug_action +{ + cda_default, + cda_none, + cda_force, + cda_yes, +}; And this preexisting one: /* Types of compressed DWARF debug sections. */ enum compressed_debug_section_type { COMPRESS_DEBUG_NONE = 0, COMPRESS_DEBUG_GNU_ZLIB = 1 << 1, COMPRESS_DEBUG_GABI_ZLIB = 1 << 2, COMPRESS_DEBUG_ZSTD = 1 << 3, COMPRESS_UNKNOWN = 1 << 4 }; Imagine we started over from scratch, and had these two orthogonal options, matching internal enums (enum compress_debug_action would be slightly different): --compressed-debug-sections-format=zlib|zstd|...|none # Iff we're compressing, what format shall we use? --compress-debug-sections=no|yes|sizewin # Are we compressing debug sections? When? # # - "no" - never, we're not compressing. # # - "yes" - always, we're compressing, using the format specified # by --compressed-debug-sections-format (and if that is "none", well, # you still get what you asked for). # # - "sizewin" - compress if there's a size win. Like "yes", if the format is # "none", well, this becomes a nop. ... then the semantics of mixing these options, or what happens when you repeat them would be much more obvious: - You can specify '--compressed-debug-sections-format' multiple times. The last wins. - You can specify '--compress-debug-sections' multiple times. The last wins. - Changing '--compressed-debug-sections-format' does not affect the value of '--compress-debug-sections'. - Changing '--compress-debug-sections' does not affect the value of '--compressed-debug-sections-format' Now, we can't use those option names with that meaning, though, because '--compress-debug-sections' today already has the meaning of selecting the compression format. But that just means we would need to pick different names, like for example: --compress-debug-sections=zlib|zstd|none # Iff we're compressing, what format shall we use? --nocompress-debug-sections # Shorthand for --compress-debug-sections=none --compress-debug-sections-when=never|always|sizewin # Are we compressing debug sections? When? # # - "never" - never, we're not compressing. # # - "always" - always compress, using the format specified by # by --compress-debug-sections (and if that is "none", well, # you still get what you asked for). # # - "sizewin", compress if there's a size win. Like "always", respects # the format specified by --compress-debug-sections. The semantics of mixing these options, or what happens when you repeat them would be obvious in the same way in the other options naming earlier: - You can specify '--compress-debug-sections' multiple times. The last wins. - You can specify '--compress-debug-sections-when' multiple times. The last wins. - Changing '--compress-debug-sections' does not affect the value of '--compress-debug-sections-when'. - Changing '--compress-debug-sections-when' does not affect the value of '--compressed-debug-sections' You end up with two different ways to disable compressing debug sections, but that seems OK to me. All that would be left would be bikeshed on the new option name. Pedro Alves > > As an aside: As you update the patch, please try to keep the title in > line with what the patch actually does. > > Also, ftaod, I don't mean to stand in the way of another maintainer > approving any of the forms proposed so far. This specifically also > includes the use of '+' as a separator, which I personally don't > (currently) intend to approve. > > Jan >