On 2/24/23 15:26, Jan Beulich wrote: > On 24.02.2023 15:11, Tom de Vries wrote: >> 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: >>>>> 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. > > Oh, I've overlooked that you explicitly clear *none when you set *force > (my attention was mainly on the bottom of parse_compress_debug_optarg()). > I think that's more involved than necessary (possibly merely a result of > you having worked incrementally from your earlier version), and less > obviously doing the same as would happen when multiple separate options > were parsed. I've tried to simplify further. Is this more how you want it? Thanks, - Tom