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:
>>> On 23.02.2023 14:27, Tom de Vries wrote:
>>>> On 2/23/23 14:08, Jan Beulich wrote:
>>>>> On 23.02.2023 13:45, Tom de Vries via Binutils wrote:
>>>>>> Gas has an option --compress-debug-sections that allows it to generate
>>>>>> compressed debug sections.
>>>>>>
>>>>>> That does not guarantee that the debug sections are in fact compressed:
>>>>>> ...
>>>>>> $ gcc ~/hello.c -Wa,-gdwarf-5 -c -Wa,--compress-debug-sections=zstd
>>>>>> $ readelf -S -W hello.o | grep " .debug"
>>>>>>      [ 9] .debug_line       PROGBITS         0000a8 000053 00      0   0  1
>>>>>>      [11] .debug_line_str   PROGBITS         0000fb 000025 01  MS  0   0  1
>>>>>>      [12] .debug_info       PROGBITS         000120 000039 00      0   0  1
>>>>>>      [14] .debug_abbrev     PROGBITS         000159 000028 00      0   0  1
>>>>>>      [15] .debug_aranges    PROGBITS         000190 000030 00      0   0 16
>>>>>>      [17] .debug_str        PROGBITS         0001c0 000039 01  MS  0   0  1
>>>>>> ...
>>>>>>
>>>>>> Sensibly so, they're only compressed if that provides a size benefit.
>>>>>>
>>>>>> However, for the purposes of testing components consuming dwarf
>>>>>> we may want the sections to be compressed regardless.
>>>>>>
>>>>>> Add a new option --force-compress-debug-sections that ignores the size
>>>>>> heuristic, such that we have instead:
>>>>>> ...
>>>>>> $ gcc ~/hello.c -Wa,-gdwarf-5 -c -Wa,--compress-debug-sections=zstd \
>>>>>>      -Wa,--force-compress-debug-sections
>>>>>> $ 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
>>>>>> ...
>>>>>>
>>>>>> Advertised as:
>>>>>> ...
>>>>>> $ as --help 2>&1 | grep compress
>>>>>>      --compress-debug-sections[={none|zlib|zlib-gnu|zlib-gabi|zstd}]
>>>>>>                              compress DWARF debug sections
>>>>>>      --nocompress-debug-sections
>>>>>>                              don't compress DWARF debug sections
>>>>>>      --force-compress-debug-sections
>>>>>>                              force compression of DWARF debug sections
>>>>>
>>>>> No objection in principle, but have you considered making this a new
>>>>> sub-option to --compress-debug-sections, i.e. compress-debug-sections=force?
>>>>
>>>> I did consider adding a "force-" prefix variant for all the non-none
>>>> sub-options, but decided to go with the simplest solution first.
>>>>
>>>> Your suggestion, --compress-debug-sections=force is more orthogonal,
>>>> though it breaks the pattern that all the sub-options are mutually
>>>> exclusive.
>>>>
>>>> We could have it be standalone, so you'd do:
>>>> --compress-debug-sections=zstd --compress-debug-sections=force.
>>>>
>>>> Or instead combined: --compress-debug-sections=force,zstd.  Harder to
>>>> parse though, I suppose.
>>>
>>> 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
...

> 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.

Thanks,
- Tom