From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 0965A3857C45 for ; Wed, 23 Sep 2020 17:14:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0965A3857C45 Received: by mail-il1-x143.google.com with SMTP id x18so329004ila.7 for ; Wed, 23 Sep 2020 10:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qDcnGsUc5RA2vKP7GD4apQmUn5Z+PLbktSan7Yqh2m4=; b=QkJgzY/jpwvJ95zOMqqbPFF1hFuron0j+QA8WkO/b4YW6LpTzGBvhUZfAFqwR79wTd Svm0nCmWSd5GfrqRr4rzN874GdVg8BJ1MqX/9IUzDBU9i1IpNmjURI37t8vucrPGJHCW Mn3HiON7j2po3lueNNMZEJpuBKrtUnlhhgv9Gftlfr5qTV3IjGlOb330sCSwOJB3vzfs xjGv7mnXdH3wbte7DpJQ7O+7V8KHLjzmQeRxZ5C8vrevvvts2nTRhYc30YPRRID5nDQ/ Tenql4dB/biuWjOtsktVG0zbqL8CUso1/Kp9c7bTUeancZGyIJdRnqp1ScsteEKoCg89 BFAw== X-Gm-Message-State: AOAM530tGltzpvuelU579G/7r6vi0twCJNLTRR9naIB+kWzI2igIzWSo dHr6cy7XVgKMxrj12V6XggQOF7reTmUjAODPGIDRRpQvyu0= X-Google-Smtp-Source: ABdhPJybCtNZ8zbKas3xFJMIOosVlhKgGXFvZfbI2SSsG1iDgbthTq0xH4F/xtc+sGIopDJLVgpRkPsVzbrTohH414Q= X-Received: by 2002:a92:1589:: with SMTP id 9mr687022ilv.292.1600881253431; Wed, 23 Sep 2020 10:14:13 -0700 (PDT) MIME-Version: 1.0 References: <20200923010930.xtc4mgmxsoesohkn@gmail.com> <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> <20200923165211.fr4rqzp5uqqmrufq@jozef-acer-manjaro> In-Reply-To: <20200923165211.fr4rqzp5uqqmrufq@jozef-acer-manjaro> From: "H.J. Lu" Date: Wed, 23 Sep 2020 10:13:37 -0700 Message-ID: Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag To: Michael Matz , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Wed, 23 Sep 2020 17:14:16 -0000 On Wed, Sep 23, 2020 at 9:52 AM Jozef Lawrynowicz wrote: > > On Wed, Sep 23, 2020 at 01:51:56PM +0000, Michael Matz wrote: > > Hello, > > > > On Wed, 23 Sep 2020, H.J. Lu via Binutils wrote: > > > > > > I think that: > > > > > > > > > .section .text,"ax" > > > > > ... > > > > > foo: > > > > > ... > > > > > .retain > > > > > retained_fn: > > > > > ... > > > > > > > > is some nice syntactic sugar compared to: > > > > > > > > > .section .text,"ax" > > > > > ... > > > > > foo: > > > > > ... > > > > > .section .text,"axR" > > > > > retained_fn: > > > > > ... > > > > > > > > It's also partly for convenience; we have other directives which are > > > > synonyms or short-hand for each other. > > > > > > > > > > You don't need to keep the whole section when only one symbol should > > > be kept. Please drop the .retain directive. GCC, as and ld should do the > > > right thing with > > > > > > .section .text,"ax" > > > ... > > > foo: > > > ... > > > .section .text,"axR" > > > > > > retained_fn: > > > > > > where foo can be dropped and retained_fn will be kept. > > > > This is not what we discussed at the ABI list, the flag is per section, so > > either the whole section is retained or not. What you describe is > > something else that would work on a per symbol basis, which would have to > > be specified in a different way and might or might not be a good idea. > > But let's not conflate these two. > > Also, the linker cannot currently dissect a section and remove a > particular unused symbol anyway. Since garbage collection only operates > on the section level, marking the section itself as "retained" seems > most appropriate. It can be done. If you put your branch on https://gitlab.com/x86-binutils/binutils-gdb I can help you implement it. > As an aside.. we would run into limitations in the ELF format if trying > to mark the symbol itself as "retained". You cannot define "retain" as a > new symbol type or binding, because there is not a one-to-one mapping of > "retain" to the existing symbol types and bindings i.e. a retained > symbol might be STT_OBJECT or STT_FUNC, or STB_LOCAL or STB_GLOBAL. > st_other could be another place to store the requirement to "retain" a > symbol, but all those available bits are used up (albeit some > unofficially). > > I'm not saying there's no way it could be done, but these are the > hurdles I discovered when considering that path to implementing the > "retain" behavior. > > > About the .retain syntactic sugar: I also think it's not necessary, the > > .section directive with R flag merging is good enough IMHO. > > I'm OK with removing the .retain directive, since there is some > consensus it is not necessary. Also, I thought it made life easier for > GCC to mark sections as retained by omitting the section name from the > directive, but I've discovered a way around that now. > > Thanks, > Jozef -- H.J.