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.133.124]) by sourceware.org (Postfix) with ESMTPS id 2EB1F3858416 for ; Mon, 7 Nov 2022 11:22:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2EB1F3858416 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=1667820161; 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; bh=IM/qPumrA6qZDigiXiP+aY24XkWSjoQqD4GuuEurriY=; b=LlgLmQZy1ROr4X5haSH3DqVuiUbo88aDVVjsCK9T5OM1JT+CJlR5Bb+rVhcl1+09VULH1A yzFXDH8uUlRj4BtXW1MZ03I9aaEK292VYlrDauGK2LMgeWk0HZ+RmAFprwa8qOjbFC3SYa TkqWMmvABwAy6wIwyt/XZLI8+osEq/Q= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-132-XYsNJRo7Pn2PI8s2BcxN8w-1; Mon, 07 Nov 2022 06:22:40 -0500 X-MC-Unique: XYsNJRo7Pn2PI8s2BcxN8w-1 Received: by mail-qt1-f198.google.com with SMTP id c19-20020a05622a059300b003a51d69906eso7830646qtb.1 for ; Mon, 07 Nov 2022 03:22:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from: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=IM/qPumrA6qZDigiXiP+aY24XkWSjoQqD4GuuEurriY=; b=Onz0Z9NJKYOwF2CORgmgabtez49dYOxLnyyDYKETc0Pv1QNcLPwXptHxKXhMCHDl0r M3YZFm+a23cQRCF9C7uKDRJVXLAps3GsEfrO0xnLMhE075zyzA00tCiEfdDEyQgjpeF/ FZ3BXkUSWu+vsiJ5I47K0cxJjxLuZgUhC/a/zodKQsLYoaxjRGel4kV3q/ZdN1GkJ/2p Wv9rgerrCiCG4rZoZChYcrzYgN88YGGWezAL0J8+WVYuTbfNlcxmiIkEvQyPHQHY9nLQ 2CwU1xtoTql30bAS+6B7qvWrMv41CN7YuDFhr5tPG2c2t8w6kKAGizMEljrZAJyjEVNq Q+yg== X-Gm-Message-State: ACrzQf1uBrtq+UsaoUK4r8kUkZrvcJsFa/ReeN1tCgZhHkw3j9n8YY7s yW2MechdHP2DPdS7avFxtarTB4HManyb/Z8Qlkws9/uOob4B9qpJ+0BI/xWS+Dq7zw5cKhMqg3o 44lHFgBUROb0ZEGREKAYSxQxwuGO1V1hs3PMhlc70l0/Qsfh23Qvc200V7cuiQXKAcg== X-Received: by 2002:ac8:706:0:b0:3a5:6f39:4bd4 with SMTP id g6-20020ac80706000000b003a56f394bd4mr10778035qth.528.1667820160005; Mon, 07 Nov 2022 03:22:40 -0800 (PST) X-Google-Smtp-Source: AMsMyM5CrZ3vLJrNZkfZpeNmoRQqDqGzztcU/3MH1nqEgxHzP770e3/j9fb2r+OrZ+AwzPFfHqopXw== X-Received: by 2002:ac8:706:0:b0:3a5:6f39:4bd4 with SMTP id g6-20020ac80706000000b003a56f394bd4mr10778025qth.528.1667820159758; Mon, 07 Nov 2022 03:22:39 -0800 (PST) Received: from [192.168.1.18] (adsl-164-85.freeuk.com. [80.168.164.85]) by smtp.gmail.com with ESMTPSA id u12-20020a37ab0c000000b006e54251993esm6529286qke.97.2022.11.07.03.22.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 03:22:39 -0800 (PST) Message-ID: Date: Mon, 7 Nov 2022 11:22:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 To: gnu-gabi@sourceware.org Cc: "Guillermo E. Martinez" From: Nick Clifton Subject: Using section flags to indicate stripable or persistent sections 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,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, We would like to suggest an extension the ELF section flags which can be used to indicate sections that should, or should not, be stripped when removing debug information. The problem we are trying to address is that different stripping tools (strip, eu-strip, llvm-strip) have different heuristics for deciding which sections should be removed when stripping debug information. In order to fix this we are proposing two new section flags: GNU_SHF_CAN_BE_STRIPPED GNU_SHF_DO_NOT_STRIP These would be set by the assembler and/or linker to indicate sections that should be removed when stripping and sections which must not be removed when stripping. It would be an error if both flags were present on a given section, and if neither flag is present then the stripping tool would fall back on its built in heuristics. In addition we need new flags for the assembler's .section directive (suggestion: 'D': can be stripped, 'K' do not strip). This email is to ask if you think that this idea has merit, and if so, are there any guidelines for writing and submitting a formal specification ? Cheers Nick