From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88855 invoked by alias); 1 Feb 2020 18:21:53 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 88846 invoked by uid 89); 1 Feb 2020 18:21:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*i:sk:CAMe9rO, H*F:D*me, groupsgooglecom, H*MI:sk:av9F1Hm X-HELO: mail-pl1-f196.google.com Received: from mail-pl1-f196.google.com (HELO mail-pl1-f196.google.com) (209.85.214.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Feb 2020 18:21:51 +0000 Received: by mail-pl1-f196.google.com with SMTP id p11so4127176plq.10 for ; Sat, 01 Feb 2020 10:21:51 -0800 (PST) Return-Path: Received: from localhost (c-71-204-169-238.hsd1.ca.comcast.net. [71.204.169.238]) by smtp.gmail.com with ESMTPSA id w28sm6307190pgl.20.2020.02.01.10.21.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Feb 2020 10:21:49 -0800 (PST) Date: Sat, 01 Feb 2020 18:21:00 -0000 From: Fangrui Song To: "H.J. Lu" Cc: Binutils Subject: Re: [PATCH] x86: Keep __patchable_function_entries sections with --gc-sections Message-ID: <20200201182148.722e4cc57xy2vyxb@gmail.com> References: <20200201162613.2023476-1-hjl.tools@gmail.com> <20200201173429.ep5siwkbhz5osehk@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-SW-Source: 2020-02/txt/msg00013.txt.bz2 On 2020-02-01, H.J. Lu wrote: >On Sat, Feb 1, 2020 at 9:34 AM Fangrui Song wrote: >> >> On 2020-02-01, H.J. Lu wrote: >> >After all text sections have been garbage collected, if a >> >__patchable_function_entries section references a section which >> >wasn't marked, mark it with SEC_EXCLUDE and return NULL. Otherwise, >> >keep it. >> > >> >Should it be handled in _bfd_elf_gc_mark_extra_sections? >> >> Thanks for paying attention to these feature requests. >> >> I referenced GNU as and ld requests at >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492#c2 >> If we >> >> * implement SHF_LINK_ORDER > >I am not sure if overloading (abusing?) SHF_LINK_ORDER is a good idea. It is an extension, but it is agreed by multiple parties on https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/eGF9A0AnAAAJ , including HP-UX and Solaris developers. >> * allow multiple sections with the same name ("unique") > >This is orthogonal to this. I have a question on assembly syntax: > >https://sourceware.org/bugzilla/show_bug.cgi?id=25380#c1 > >> * teach GCC to use SHF_LINK_ORDER and "unique" (see https://gcc.gnu.org/ml/gcc/2020-01/msg00067.html) >> >> An ad-hoc gc marking will be unnecessary. > >We need to scan relocations in _patchable_function_entries section for >references to garbage collected sections. We can either check section >name or a SHF_XXX. But I don't know if SHF_LINK_ORDER is a good >approach. We don't need to if we use multiple __patchable_function_entries sections. Multiple sections are a must due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195#c1 (COMDAT) > A symbol table entry with STB_LOCAL binding that is defined relative > to one of a group's sections, and that is contained in a symbol table > section that is not part of the group, must be discarded if the group > members are discarded. References to this symbol table entry from > outside the group are not allowed. The __patchable_function_entries creation logic I implemented in clang: foreach function foo find the first function label defined in foo's section, name it $associated ($associated can have 2 reasonable values, w/ or w/o -ffunction-sections) get or create an id for $associated, say, $unique if foo is in a COMDAT named $comdat .section __patchable_function_entries,"awo",@progbits,$associated,comdat,$comdat,unique,$unique else .section __patchable_function_entries,"awo",@progbits,$associated,unique,$unique This approach uses feature requests I referenced in *direct* links of https://gcc.gnu.org/ml/gcc/2020-01/msg00067.html plus https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492#c2 , and addresses all bugs I filed. >> SHF_LINK_ORDER has been used in a few sanitizers. Now we know >> __patchable_function_entries can benefit from it. In the future, they >> may be instances. We really need a general solution. > > >-- >H.J.