From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100991 invoked by alias); 3 Feb 2020 00:57:28 -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 100983 invoked by uid 89); 3 Feb 2020 00:57:27 -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*MI:sk:CAMe9rO X-HELO: mail-pf1-f196.google.com Received: from mail-pf1-f196.google.com (HELO mail-pf1-f196.google.com) (209.85.210.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Feb 2020 00:57:25 +0000 Received: by mail-pf1-f196.google.com with SMTP id i6so6665331pfc.1 for ; Sun, 02 Feb 2020 16:57:25 -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 a195sm17860386pfa.120.2020.02.02.16.57.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Feb 2020 16:57:23 -0800 (PST) Date: Mon, 03 Feb 2020 00:57:00 -0000 From: Fangrui Song To: "H.J. Lu" Cc: Binutils , Szabolcs Nagy Subject: Re: [PATCH] Issue an error for GC on __patchable_function_entries section Message-ID: <20200203005722.q7dyk6bajvxfdunp@gmail.com> References: <20200201162613.2023476-1-hjl.tools@gmail.com> <20200201173429.ep5siwkbhz5osehk@google.com> <20200201182148.722e4cc57xy2vyxb@gmail.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/msg00023.txt.bz2 On 2020-02-02, H.J. Lu wrote: >On Sat, Feb 1, 2020 at 10:21 AM Fangrui Song wrote: >> >> 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. >> > >Here is a linker patch to issue an error to avoid corrupt >linker output. > >-- >H.J. A typo in the description. - .section __patchable_function_entries,"awo",%progbits,_start + .section __patchable_function_entries,"aw",%progbits GCC's output is the below (no SHF_LINK_ORDER). I don't have an opinion whether !SHF_LINK_ORDER should be worked around in GNU ld. CC Szabolcs who fixed AArch64 BTI https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01942.html