[PATCH] gas: Add --force-compress-debug-sections

[Tom de Vries]

On 2/24/23 14:23, Jan Beulich wrote:
> On 24.02.2023 13:21, Tom de Vries wrote:
>> On 2/24/23 12:28, Jan Beulich wrote:
>>> On 24.02.2023 11:52, Tom de Vries wrote:
>>>> On 2/23/23 14:44, Jan Beulich wrote:
>>>>> I think both should be allowed. In a complex build system it may be
>>>>> different entities setting "how" and "whether". (To me "none" falls in
>>>>> the "whether" category together with "force", and it also can be seen
>>>>> as falling in the "how" category together with "zlib" etc. In Linux
>>>>> Kconfig, for example, I'd see this being expressed as first a "whether"
>>>>> choice [yes/maybe/forced] and then a "how" choice dependent upon
>>>>> "whether != none".)
>>>>>
>>>>
>>>> I gave this approach a try.
>>>
>>> Any specific reason you chose + as the separator instead of the more
>>> conventional , ?
>>
>> Yes, I initially went for ',', but ran into:
>> ...
>> $ gcc ~/hello.c -Wa,-gdwarf-5 \
>>       -Wa,--compress-debug-sections=zstd,force -c -v
>>     ...
>>    as -v --64 -gdwarf-5 --compress-debug-sections=zstd force -o hello.o \
>>      /tmp/ccOUMqHL.s
>>     ...
>> Assembler messages:
>> Error: can't open force for reading: No such file or directory
>> ...
> 
> Hmm. I have to admit that I'm not happy with +, irrespective of this
> issue. I wonder what other maintainers think - Nick, Alan?
> 

AFAIU you're proposing to use "-Xassembler 
--compress-debug-sections=zstd,force" in this case instead of -Wa.

>>> I also wouldn't see anything wrong with something
>>> like "...=force,zstd,none" - the last one(s) win. That's no different
>>> from specifying a second instance of the option. And without that it
>>> looks as if the parsing would end up simpler.
>>
>> OK, gave that a try.
> 
> That's still accumulating none and force across the entire sequence
> (and then giving none priority over force, no matter that force may
> have been specified last),

Um, so you're saying that none+zstd+force is currently interpreted as none?

Lets try:
...
$ gcc ~/hello.c -c -Wa,-gdwarf-5 -Xassembler 
--compress-debug-sections=none+zstd+force
$ readelf -S -W hello.o | grep " .debug"
   [ 9] .debug_line       PROGBITS        0000a8 000064 00   C  0   0  8
   [11] .debug_line_str   PROGBITS        000110 000046 01 MSC  0   0  8
   [12] .debug_info       PROGBITS        000158 000046 00   C  0   0  8
   [14] .debug_abbrev     PROGBITS        0001a0 000049 00   C  0   0  8
   [15] .debug_aranges    PROGBITS        0001f0 000034 00   C  0   0  8
   [17] .debug_str        PROGBITS        000228 00005a 01 MSC  0   0  8

...

So, that doesn't seem to be the case, compression is done, as expected.

Thanks,
- Tom

> rather than handling things the same as
> when multiple options are specified. With accumulation partially
> removed parsing became less involved, but it can be yet more simple
> when that accumulation is dropped.
> 
> In case of contention maybe best to not allow a sequence and hence
> require (in certain cases) two instances of the option to be passed?
> At the very least that's then easier to parse.