From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by sourceware.org (Postfix) with ESMTPS id F14CA3850400 for ; Mon, 28 Sep 2020 12:28:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F14CA3850400 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-x444.google.com with SMTP id s12so1077932wrw.11 for ; Mon, 28 Sep 2020 05:28:25 -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=jKize5Q3uAgit2jcnr9toyCmCvCm1fnEJjqsdIPWo7k=; b=AGiSQ1Mms4NZ6p9Hkaho7NozDzuwgzu+SFVtg+p1o8N9yxlZGtF4lf841dwN2zJxc4 3wzEvvrz5ToUh99Jy0F2yjGCcYrvNvsVX4S3yD5HIAJG/YI8lilSKhb81BSjnUySCwB4 H3NQYj43vMgMY1PAqzyK2JHwh0u3AUh1qXVEofIogNEAKfsEzthExW62XLQ7maS4aNQa COus6sXhk7vMNbhNpuzW8xBkxZDzmUIiIihcJ9NGa/YlQLSG0BroTGFGh1yrS1xXqB2h 0fYZ55OsCx200kv9e1AODN3YO4BExhLULonXIloRTKGOZm9oVg4ocEdbMIdz2sE+vvFw em+g== 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=jKize5Q3uAgit2jcnr9toyCmCvCm1fnEJjqsdIPWo7k=; b=W/qk7y7K/gofHxqIVS/h0J645FrThv9hBF2NL6hPXhxiAb+Gp47o38qRQ8gAPkM/n3 sXBRGKNxqpkFjJlxWypfO+B5KIxxRY7jM6aERK0YNNAzWT/bPbfAucaJ+PyDoQ5/0uJ8 DzBmlSExLuF6SYrEKdC5STIVzgXSriNrxRQccEpUI9UJRtkOM0KIDSoP/d1AhFBbu1d/ PFyWWognk99t++SBXEhkGmUvYsqLfksPnB7UNnimNx1c662eJTG1vhgxgL9BotyentHz LdhKH5hzY65vvZNWUWHhW+ZUjd4NZudItbthRPPI1TUkTdH6IRkoGb21XM/9IYWOABh8 Gyvg== X-Gm-Message-State: AOAM530sdMhxF2rVR5XWVmxSX04o3kpTwvxstJsJu8VIKSqpOaeNdlKy NbhkF02w01tIjQDY3nAGcY50zt7mYLa0KQ== X-Google-Smtp-Source: ABdhPJzvrAdM99PFR/7aMSziQSqOmE3pHP910+kxLeIIMon39WeNEl9aV/yptqJ+bDQuXf2ns6sH7g== X-Received: by 2002:adf:a3ca:: with SMTP id m10mr1519043wrb.104.1601296105046; Mon, 28 Sep 2020 05:28:25 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id f14sm1380962wrv.72.2020.09.28.05.28.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2020 05:28:24 -0700 (PDT) Date: Mon, 28 Sep 2020 13:28:22 +0100 From: Jozef Lawrynowicz To: Pedro Alves Cc: binutils@sourceware.org Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200928122822.nql5aatbpo7kr5si@jozef-acer-manjaro> Mail-Followup-To: Pedro Alves , binutils@sourceware.org References: <20200922202933.kgflmtnwzkdrmrvs@jozef-acer-manjaro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.9 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: Mon, 28 Sep 2020 12:28:27 -0000 On Mon, Sep 28, 2020 at 12:35:28PM +0100, Pedro Alves wrote: > On 9/22/20 9:29 PM, Jozef Lawrynowicz 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 ...". 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. Jozef > > Pedro Alves