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 EF72C3858D38 for ; Mon, 7 Nov 2022 11:04:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF72C3858D38 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=1667819088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nf/SR+qo/eNFB0ZSNN0TLwJbf/lQjqim1ORZpNONg5g=; b=h4PB/Cn2Lip8vvWs5Wrpr2l371cubUWdI9rTccYZ8OUqhz6swPBH6aC+gIfnWj2rvOstDY HD0cvFOyhhsMcqeDQ8qsKR41pZoc3+0NULw+f0/fmYWsYLEqKVEfrA7WwK2rbg8ZfEbSqa kTmrh6JUpF6PSPSoglUTeB5ldJc60gY= 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-640-ZzwsQN5nNJaNqyAX-uPyCA-1; Mon, 07 Nov 2022 06:04:47 -0500 X-MC-Unique: ZzwsQN5nNJaNqyAX-uPyCA-1 Received: by mail-qk1-f198.google.com with SMTP id w13-20020a05620a424d00b006e833c4fb0dso9771272qko.2 for ; Mon, 07 Nov 2022 03:04:47 -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:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nf/SR+qo/eNFB0ZSNN0TLwJbf/lQjqim1ORZpNONg5g=; b=vrjslvzX1kpcKx+wqhEff8vI5KsuxLrW5rS4vF66hJ7W942O/gPdqSJuF91d2eiMJJ oMzObcR4Ay37htX6jTw666qQbEWHWsw1OKYoXGUOp08xidqxWi/5DnreTxpq3O+edh/s kjvZeD6mvH0e1I+e4BcGgrK4lKoTdx5+qf3tzOFU8VpAUuze4Hx10is+9KJ4JBm8vmJe TgKSjvRPdTmOBbkQNk25A/BFxMIfga9v3obPnqvn+VWGYoWY1upUEtrbf/TRSejjAfoe Ht0yCN03NKqMTuCMAyYOyipyFFlQTP9cM7mm09vKjFSPWGq9/QeLEDV34V2XXEd7V2uK zspA== X-Gm-Message-State: ACrzQf2Zs+kseklcUgqCPK0jQpZBjcuwNgIizxq08QxiGxUipiTddNvn 97QGbGVoUHSrziJuz9ltpPwenBb5sP93RdzxWxbgh+73wts2LcN1W4OFOJjAtZMc/3vyJ7gLGAU d0yoUOTFfpZ+7dYWGJQ== X-Received: by 2002:a05:620a:8013:b0:6fa:93b1:a061 with SMTP id ee19-20020a05620a801300b006fa93b1a061mr464312qkb.446.1667819087272; Mon, 07 Nov 2022 03:04:47 -0800 (PST) X-Google-Smtp-Source: AMsMyM6KjaKEjm4t0+nisySSZLhYtxTVctnTty1ME1RhLDRIegU8oBgEnIMhwyAtw4UjngZ5gdZ6qA== X-Received: by 2002:a05:620a:8013:b0:6fa:93b1:a061 with SMTP id ee19-20020a05620a801300b006fa93b1a061mr464310qkb.446.1667819087021; Mon, 07 Nov 2022 03:04:47 -0800 (PST) Received: from [192.168.1.18] (adsl-164-85.freeuk.com. [80.168.164.85]) by smtp.gmail.com with ESMTPSA id n16-20020a05620a295000b006f9ddaaf01esm6692757qkp.102.2022.11.07.03.04.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 03:04:46 -0800 (PST) Message-ID: <511c27ce-7b04-ea2d-9a62-a110f1f11d87@redhat.com> Date: Mon, 7 Nov 2022 11:04:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 To: "guillermo.e.martinez at oracle dot com" , gnu-gabi@sourceware.org References: From: Nick Clifton Subject: Using section flags to indicate strip 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,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