From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 14B70384B13C for ; Tue, 29 Sep 2020 13:22:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 14B70384B13C 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-wr1-x442.google.com with SMTP id c18so5360167wrm.9 for ; Tue, 29 Sep 2020 06:22:38 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=Fd3xuK3Z0mx/S7Bx+UwE0eHUFwiQdxNi5FuFSdsINas=; b=k0RVsceE/VD4kCTvoE3X2/xPaLyatjb3HmW/8fXuIE82qyt4rGu8ai9hrs4AzpL3vk gDOrQmFTEqbgLjLyhGpH1ue3oeuP22Sdl+Qzfl9jC5+d5z7brSC5eTEtZVd9vDqYFEYO ppMcyl5YBaaSqgP9kSHvD3X/jd6O+IZP1oo1K8LdVweKTSerne7SLCZRtii2VaflIbnF RQrGFsgLsMRoXWlv803y+mAr8zjJoJpGCUgd7mzzhER9J1Z8cnD+p6DzbOp9cuUhUVc6 v7bUr6WT7AigT9/loUti+RyFB3oN7DJ2PWbas3dt9BGTeXDefMX+TPmNSPkBocKUL9oS asUw== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=Fd3xuK3Z0mx/S7Bx+UwE0eHUFwiQdxNi5FuFSdsINas=; b=dniFyrhva/HFRx60BzW03imnt4rNWDaLPbHKNmGECN5gWjfpDZaw1FC2qGG2bUk0RL EzapYrH/lgQCBhXI/hoYbrMMvLqn5bHrEeLzp9gvBC2VAktHVId/CjwNh5xb4TzwPIKK BX6GNLVRUV5Cd04hO6VEKnFk+q0pRYvrEvG4u+JKNA1x4o0m3HnAWQ+W6QCSobGVoA4s N7p+8klEMSuNmd3EoqgsQPTi0NIiCHFSYOdA37jJsBwpPqgXXnFAlFGn87YJijESsz3p CxEvI5/PGMX+rYO+/bo2tNIq0Omhnli6/o5mIaTc16dQZAZ1rvsra1jOn1ABpFY2bhCU tffg== X-Gm-Message-State: AOAM531EHLd01qRnH8QbtiSZJI+pizz8sdWrmvaR0VXtUmlYHbILf5We YhRxrpPn2Ptg9whegVgzCWFKRGdJk6QBog== X-Google-Smtp-Source: ABdhPJyFZhRSmW2+Dt4183QvYQ1kFJXPSTFbe4tNyAUxh7dkaK5KjS4zADQk70WThmjNZHXwGbzPPw== X-Received: by 2002:adf:e7ce:: with SMTP id e14mr4213380wrn.43.1601385757136; Tue, 29 Sep 2020 06:22:37 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id k84sm5684649wmf.6.2020.09.29.06.22.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Sep 2020 06:22:36 -0700 (PDT) Date: Tue, 29 Sep 2020 14:22:35 +0100 From: Jozef Lawrynowicz To: Michael Matz Cc: Pedro Alves , binutils@sourceware.org Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200929132235.mjcaxw4skh5sqwh5@jozef-acer-manjaro> Mail-Followup-To: Michael Matz , Pedro Alves , binutils@sourceware.org References: <20200922202933.kgflmtnwzkdrmrvs@jozef-acer-manjaro> <20200928122822.nql5aatbpo7kr5si@jozef-acer-manjaro> <7982913d-90a3-c435-d152-b18f46cad62c@palves.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.8 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: 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:22:39 -0000 On Tue, Sep 29, 2020 at 01:18:31PM +0000, Michael Matz wrote: > 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. Yep, thanks Michael. I'm working on the GCC implementation at the moment, I'll review what happens if "used" implies SHF_GNU_RETAIN before I submit to gcc-patches, and that aspect of the implementation can be discussed there. Jozef > > > Ciao, > Michael.