From: Jan Beulich <jbeulich@suse.com>
To: Pedro Alves <pedro@palves.net>
Cc: binutils@sourceware.org, Michael Matz <matz@suse.de>,
Nick Clifton <nickc@redhat.com>, Alan Modra <amodra@gmail.com>,
Tom de Vries <tdevries@suse.de>
Subject: Re: [PATCH] gas: Add --force-compress-debug-sections
Date: Mon, 27 Feb 2023 15:07:29 +0100 [thread overview]
Message-ID: <df5c02c9-995a-c305-8461-bf19d8ee2050@suse.com> (raw)
In-Reply-To: <70ee7e78-080f-ddce-9916-608bd8733e66@palves.net>
On 27.02.2023 14:44, Pedro Alves wrote:
> 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.
That would be okay with me as well, but (in part to avoid ...
> All that would be left would be bikeshed on the new option name.
... this aspect) I fail to see why a single option won't do:
--compress-debug-sections=zlib|zstd|no|yes|sizewin
Since the sub-options are distinct sets (alongside "no" one could add "none"
if wanted, to separate "method: no compression" from "don't compress", which
I think would then also eliminate the ambiguity referred to earlier on
[still visible in context above]), within each set your "last wins" would
apply equally. And in fact that was the main reason for my original response
back to Tom: I view the proliferation of command line options (not just
here, but in general) as a scalability issue. Therefore my rule of thumb is
that things which belong together are best grouped under a single top-level
option.
Jan
next prev parent reply other threads:[~2023-02-27 14:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 12:45 Tom de Vries
2023-02-23 13:08 ` Jan Beulich
2023-02-23 13:27 ` Tom de Vries
2023-02-23 13:44 ` Jan Beulich
2023-02-24 10:52 ` Tom de Vries
2023-02-24 11:28 ` Jan Beulich
2023-02-24 12:21 ` Tom de Vries
2023-02-24 13:23 ` Jan Beulich
2023-02-24 14:11 ` Tom de Vries
2023-02-24 14:26 ` Jan Beulich
2023-02-24 14:57 ` Tom de Vries
2023-02-27 9:03 ` Jan Beulich
2023-02-27 11:43 ` [PATCH] gas: Add --compress-debug-sections=force Tom de Vries
2023-02-27 11:51 ` Jan Beulich
2023-02-27 13:44 ` [PATCH] gas: Add --force-compress-debug-sections Pedro Alves
2023-02-27 14:07 ` Jan Beulich [this message]
2023-02-27 23:24 ` Tom de Vries
2023-02-28 0:19 ` Tom de Vries
2023-02-28 13:21 ` Pedro Alves
2023-02-28 12:49 ` Pedro Alves
2023-02-23 15:23 ` Michael Matz
2023-02-23 15:28 ` Tom de Vries
2023-02-23 15:44 ` Michael Matz
2023-02-23 15:46 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=df5c02c9-995a-c305-8461-bf19d8ee2050@suse.com \
--to=jbeulich@suse.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=matz@suse.de \
--cc=nickc@redhat.com \
--cc=pedro@palves.net \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).