From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 8161438582BC for ; Mon, 7 Nov 2022 13:33:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8161438582BC Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id B8F411F8A3; Mon, 7 Nov 2022 13:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1667828033; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yMA5Mutcssa9tuAb73frWi5Dh7ATiL23RYRFnrzeFcU=; b=Dn0Remd0pY7X6Z4xTImoLpRXG/prYdYsxvdJkZDfg5tbdJRCee5IrMfnUiX9PpVeUvYIC7 HVQZDeJNbFv1y28BoPjlTRXyInSvJKoz7ehTsmPUNHF+popMbcspMRnPaknZ0N4fNEc0iR mDKnaIpp0BdVOjqWLSMiAnPhOsHVhy4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1667828033; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yMA5Mutcssa9tuAb73frWi5Dh7ATiL23RYRFnrzeFcU=; b=7RzYk35u4iZCmUxg4Sn07Or9Hv8G9LSNBeTxEqNmsx3kJskFzWea6a2TucHbfDMNQ3nJEe 32zoM+h9kK/90XAQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B1EEB2C143; Mon, 7 Nov 2022 13:33:53 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id B2B8F64E2; Mon, 7 Nov 2022 13:33:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id B013C6289; Mon, 7 Nov 2022 13:33:53 +0000 (UTC) Date: Mon, 7 Nov 2022 13:33:53 +0000 (UTC) From: Michael Matz To: Nick Clifton cc: gnu-gabi@sourceware.org, "Guillermo E. Martinez" Subject: Re: Using section flags to indicate stripable or persistent sections In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,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: Hey, On Mon, 7 Nov 2022, Nick Clifton via Gnu-gabi wrote: > 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. Okay, so stripping of sections intended for debug purposes ... > 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 ... but here you have "can be stripped?". The immediate question is: for which purposes? A section might be strippable in other context than debug info. And other sections might be non-strippable for still other purposes. Just saying "please don't strip this one" conveys no useful information, except of course to inhibit each and all stripping. But was it perhaps set for other reasons than debug info? Even with those flags tools will continue to wonder if maybe this-and-that DO_NOT_STRIP option can actually be stripped in some cases. IOW: if you really want what you said, make the flags more specific (to debug info purposes). But then of course it's unclear why you wouldn't want still other flags to mean "strip-for-something-else" purposes. At which point you quickly come to the conclusion that one wants to specify some sort of type per section, and not lump everything under SHT_PROGBITS. So, I think two flag bits are not the right solution. Maybe we could use some bits of sh_type to specify a more detailed type: the low bits would just be set to the ELF SHT_xxx as appropriate, and higher bits would contain a detailed type: 0x60XXYYZZ (ZZ would be the old SHT_xxx type, and XX/YY be a detail type). Ciao, Michael. > > 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 >