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

[Jan Beulich <jbeulich@suse.com>]

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

Jan