From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 3E22D3857C65 for ; Tue, 29 Sep 2020 13:18:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3E22D3857C65 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=matz@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4F9FBAD21; Tue, 29 Sep 2020 13:18:31 +0000 (UTC) Date: Tue, 29 Sep 2020 13:18:31 +0000 (UTC) From: Michael Matz To: Pedro Alves cc: binutils@sourceware.org Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag In-Reply-To: <7982913d-90a3-c435-d152-b18f46cad62c@palves.net> Message-ID: References: <20200922202933.kgflmtnwzkdrmrvs@jozef-acer-manjaro> <20200928122822.nql5aatbpo7kr5si@jozef-acer-manjaro> <7982913d-90a3-c435-d152-b18f46cad62c@palves.net> 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=-3.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 13:18:33 -0000 Hello, On Mon, 28 Sep 2020, Pedro Alves wrote: > >>> The overall intention for this new flag is to enable a new "retain" > >>> attribute to be applied to declarations of functions and data in the > >>> source code. This attribute can be used to ensure the definition > >>> associated with the declaration is present in the linked output file, > >>> even if linker garbage collection would normally remove the containing > >>> section because it is unused. > >> > >> On a high level, this sounds pretty much like __attribute__((used)). > >> Couldn't the new section flag be wired to that attribute? > >> > >> I mean, isn't it a bug if linker garbage collection eliminates a > >> function marked with __attribute__((used)) ? > >> > >> "used > >> > >> This attribute, attached to a function, means that code must be emitted > >> for the function even if it appears that the function is not referenced." > >> > >> I was surprised to not see any mention of the "used" attribute in the > >> proposal, neither here, nor in gABI mailing list discussion linked. > >> But maybe I missed it. > > > > In an early version of the implementation, I tried tying the > > behavior to the "used" attribute, but it caused some problems. > > > > I believe the issues mainly came from the usage of "used" in > > libgcc/crtstuff.c. The functions there are static and unused, so have > > "used" applied to prevent removal by the compiler. However, that does > > not mean that all of those functions should be included in every program > > linking against libgcc. > > > > I don't remember the exact failure mode, I think it may have been that > > lots of tests were failing due to "multiple definition of ..." errors, > > or perhaps "undefined reference to ...". > > That's really strange, and to be honest, not very convincing. > > If there are multiple static functions with the same name in the same > translation unit, when you should be getting errors at compile time. > > If OTOH, your early implementation resulted in undefined references, > then it just sounds like a bug in your implementation, since as you say, > __attribute__((retain)) is a superset of __attribute__((used)). As in, > undefined references suggests the function wasn't emitted, contrary to > the point of the attribute. > > > > > The "retain" attribute implies the "used" attribute, so if the user > > wants to prevent compiler optimization AND linker optimization, "retain" > > can be used. To prevent only compiler optimization, "used" should be > > applied. > > I'm not convinced such a distinction makes sense. Maybe a small self > contained use case where the distinction makes a difference and is > desirable would help. We should remember that this thread is about the addition of the section flag, which affects but isn't directly related to how it's going to be used in source code in a high level language. If it's the pre-existing "used" or a new "retain" attribute, or an attribute at all or just left to section markers or pragmas: a discussion about that doesn't need to hold up the addition of the ELF feature. Ciao, Michael.