From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 0935A3894C35 for ; Fri, 18 Sep 2020 10:00:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0935A3894C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wm1-x335.google.com with SMTP id s13so4713953wmh.4 for ; Fri, 18 Sep 2020 03:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=n/ckT8+AUzRcZEFbFPj30ocAiO0tPAYHrUTN8HVvMoI=; b=FkqDPMoldOWAE2QBJrV8Ww5+KrU72vYPguqRzaIY2ZwVN+rFAsuvQVtzTjM3aawNx2 Gw7BI8G047JCYirZFRH+naS9okdj4/TyTEyM4Fy17pzBSY14CRSTGBGd8t9lTIoUgsIG 25YDSbrw1GqG1L9WppUZQafa/JD8crcpsi+SJJdGKFzpkzamABD6mDj6bYO80LJUGPuL axMikJ4GkgZ0a8vcfsx5+F412zN/YSJb7oL6V+CaSepzU5JkEH1VclQrLNKmhTwTj8Ot JgrucyJtyGhf4EZ42UxpLr2dVUXV4cEDuk2VlbS4KxwJzceyW0ejdqZDRquLoGgEL/Za C6dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n/ckT8+AUzRcZEFbFPj30ocAiO0tPAYHrUTN8HVvMoI=; b=nw+cYNFWwcUepJQ1YdOtAMkWzJo07npsSgB8fZLl8W/81n638j2sV7iL7SQkpOaxyT amgeopkHpM/zdiRAnp6TFo6iU8k+iitxeLnf8pbodREG3V8xHRx+kH+YkG1CbIH5mqh9 D58BOVEwmfIW3mVVTNp6n467pKyJiLWW/BAOoyCxGi4eLpPVI4mm5iXvaqFRhe1QBfMW FVk+aWbEZykvdnVSCsRkvud1lBXFshwNRCf/BGjvQxwBxnTy+kjdRPFgGRIrhOEj02xE 4vkWbBGHjq0Mv7yyubO7PZZP+TsSX3yPv7/Yp3WcHlmW+vEZMjRmJqKWXI5lk67v9rIt JGCw== X-Gm-Message-State: AOAM531+FXvsPIzpNFM9NNGKovcuQ21nrwoNFlSBhlZTC+XApzUep9Tb OaKPZao9siXxgcQJcWPsVBssfg== X-Google-Smtp-Source: ABdhPJzfeWhF82rXvLatv+MGpRbh3IlpK9m7er9dI4kE9YX8eJEqF7wvBeL9tRAx6f7afWpEc1RZrg== X-Received: by 2002:a05:600c:20b:: with SMTP id 11mr15168144wmi.147.1600423249014; Fri, 18 Sep 2020 03:00:49 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id k8sm4484397wma.16.2020.09.18.03.00.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2020 03:00:47 -0700 (PDT) Date: Fri, 18 Sep 2020 11:00:46 +0100 From: Jozef Lawrynowicz To: Carlos O'Donell , Florian Weimer Cc: gnu-gabi@sourceware.org Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag Message-ID: <20200918100046.r4c3qepxbccp7poc@jozef-acer-manjaro> References: <95e4fd3d-1486-b700-29b0-8b126b24d0ca@redhat.com> <875z8dn9xj.fsf@oldenburg2.str.redhat.com> <20200916141345.wxae5ytkyybbpcec@jozef-acer-manjaro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200916141345.wxae5ytkyybbpcec@jozef-acer-manjaro> X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 10:00:51 -0000 Hi, Where do we stand on this proposal? Unless we are trying to be protective of the remaining operating system-specific section flag bits, I don't really see any downside to going the route of SHF_GNU_RETAIN. It is very simple, the linker implementation requires only one additional line of code, and the definition precisely describes how the section should be treated. SHF_GNU_RETAIN The link editor should not garbage collect the section if it is unused. I don't think the extra detail about whether the link editor sees the section or not (in the case of libraries) is actually needed. The definition explicitly states exactly what the linker should do - do not garbage collect the section. It does not say "the linker should keep the section if it is unused". Garbage collection implies the linker "had" the section to begin with. Perhaps the ambiguity in this area comes from the word "retain" in the flag name, but again this has a precise definition. You cannot retain something you don't have. To use the word "encounters" which is used throughout the ELF spec: If the linker doesn't encounter a section, it can't retain it. The linker doesn't encounter any sections from libraries until it loads an object file needed to resolve a symbol reference, so this behavior is also precisely defined by the above definition. If we really need to, we could add emphasize the "garbage collection" aspect further: SHF_GNU_RETAIN When performing garbage collection of unused sections, the link editor should not discard the section, even if it appears unused. Are there any other objections to adding this to the GNU gABI? Thanks, Jozef