From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B2C5E3858D35 for ; Wed, 9 Nov 2022 11:09:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B2C5E3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667992156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WtssA7MAA0Fz5VAMYvWE7dTsOgEvAO+SDfltnlnSeCk=; b=fKRVPKqENtlX0hQ4y6hAprVAnv3qobq3pH2ecPQNBkD4OGLL0KgZg3RGmcWC9ARnBCxUiH Vj3IbNuwUPSJHtcKsmNlpCJ+1XO8U8X+F1+PYjq9eKrGQk2cRNiRlgMRAzXvGnVaJ73pgf G5nLfnFP7g+CoWduHLkFgCcxbPNx9FY= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-657-6ehOI0m0OKKPP9ITvRbL1w-1; Wed, 09 Nov 2022 06:09:15 -0500 X-MC-Unique: 6ehOI0m0OKKPP9ITvRbL1w-1 Received: by mail-qk1-f198.google.com with SMTP id bq13-20020a05620a468d00b006fa5a75759aso15477356qkb.13 for ; Wed, 09 Nov 2022 03:09:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WtssA7MAA0Fz5VAMYvWE7dTsOgEvAO+SDfltnlnSeCk=; b=6H90EGIC9kaGvV28gpgNwITJld3fSiBN2TSUmUHBp18wyZpUiADshWNpVUpqrLSIyX VT9alvg36W4yCZb7ufpuikXwu/Tzm+D2GaZJo5ot36z1NruFCZYL+ix/q5ZTH3K/iucC IwG7w/MII1WiSX/ifL0x08JQAKvwr5O7N6M/4n431J2FOrXwAZkp2zHqI/U4Yc8ayTHd M0Vlzl890Y0L+m8ETrxP0oh671041uz/XD+HErYETysh3U7m+8t/0+kLZJDCZaF3gRzV GaYl6JevNc3Q9+HHr2ZcIMLfdljITW7kLnyL0uIMRB2ggJb4KoTTzM+cstfydhJ22fDI j1lA== X-Gm-Message-State: ACrzQf2EUtoTPPg1slFJTevLPv0Wm3BtjOzUbjDu1D3ZnuTwbJGzuo1F LHcEleKXRUbhTjohyxLzpc8SIewMRsZQM+lXjaGJWLUQhKusJ+Emx8Wnw+NQNP/S2iZr5UjXEYL rFbSDGdW3ODv2TSlJJQ== X-Received: by 2002:a05:620a:1092:b0:6fa:2510:c353 with SMTP id g18-20020a05620a109200b006fa2510c353mr38058528qkk.352.1667992154784; Wed, 09 Nov 2022 03:09:14 -0800 (PST) X-Google-Smtp-Source: AMsMyM7OgZDZCR/+SU6Mpp9jqraxj3vuv3bqsSoisSapE3vKBQJT8SvpZCioM+KkyubnCZS4z3Hsjw== X-Received: by 2002:a05:620a:1092:b0:6fa:2510:c353 with SMTP id g18-20020a05620a109200b006fa2510c353mr38058513qkk.352.1667992154424; Wed, 09 Nov 2022 03:09:14 -0800 (PST) Received: from [192.168.1.18] (adsl-164-85.freeuk.com. [80.168.164.85]) by smtp.gmail.com with ESMTPSA id y22-20020a05620a44d600b006ec62032d3dsm11420893qkp.30.2022.11.09.03.09.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Nov 2022 03:09:13 -0800 (PST) Message-ID: Date: Wed, 9 Nov 2022 11:09:11 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 To: Alan Modra , Fangrui Song Cc: Michael Matz , gnu-gabi@sourceware.org, "Guillermo E. Martinez" References: <20221107185136.5zpzi4gnnzmbqxrm@gmail.com> From: Nick Clifton Subject: Re: Using section flags to indicate stripable or persistent sections In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Guys, OK, I agree that using the section flags is a bad idea. Using an extended section types is a nice idea, but I think that it will probably not solve the underlying problem of inconsistent section stripping - we would still need to persuade the tool maintainers to agree on which section types are stripped with each given strip option, and when new types are added the options would have to be updated. For now I think that the KISS principle applies. The strip tools have methods for explicitly specifying which sections should be removed, so whilst it might be a bit cumbersome if lots of sections have to specified, it can be done. Extension suggestion withdrawn. Cheers Nick