From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126301 invoked by alias); 7 Jan 2020 07:26:00 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 126285 invoked by uid 89); 7 Jan 2020 07:26:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=ac, UD:a.c, a.c, lightweight X-HELO: mail-pl1-f180.google.com Received: from mail-pl1-f180.google.com (HELO mail-pl1-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Jan 2020 07:25:58 +0000 Received: by mail-pl1-f180.google.com with SMTP id az3so22834808plb.11 for ; Mon, 06 Jan 2020 23:25:58 -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 u26sm77503671pfn.46.2020.01.06.23.25.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2020 23:25:56 -0800 (PST) Date: Tue, 07 Jan 2020 07:26:00 -0000 From: Fangrui Song To: gcc@gcc.gnu.org Cc: Martin =?utf-8?B?TGnFoWth?= , Alexander Monakov , Torsten Duwe , Maxim Kuvyrkov , Nick Clifton Subject: Re: -fpatchable-function-entry should set SHF_WRITE and create one __patchable_function_entries per function Message-ID: <20200107072555.rsvfb5jpbbho4hxb@gmail.com> References: <20200107060629.z7lvo74ravoppg77@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200107060629.z7lvo74ravoppg77@gmail.com> X-SW-Source: 2020-01/txt/msg00049.txt.bz2 On 2020-01-06, Fangrui Song wrote: >The addresses of NOPs are collected in a section named __patchable_function_entries. >A __patchable_function_entries entry is relocated by a symbolic relocation (e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64). >In -shared or -pie mode, the linker will create a dynamic relocation (non-preemptible: relative relocation (e.g. R_X86_64_RELATIVE); preemptible: symbolic relocation (e.g. R_X86_64_64)). > >In either case, the section contents will be modified at runtime. >Thus, the section should have the SHF_WRITE flag to avoid text relocations (DF_TEXTREL). > > > >When -ffunction-sections is used, ideally GCC should emit one __patchable_function_entries (SHF_LINK_ORDER) per .text.foo . >If the corresponding .text.foo is discarded (--gc-sections, COMDAT, /DISCARD/), the linker can discard the associated __patchable_function_entries. This can be seen as a lightweight COMDAT section group. (A section group adds an extra section and costs 3 words) >Currently lld (LLVM linker) has implemented such SHF_LINK_ORDER collecting features. GNU ld and gold don't have the features. > >I have summarized the feature requests in this post https://sourceware.org/ml/binutils/2019-11/msg00266.html > >gcc -fpatchable-function-entry=2 -ffunction-sections -c a.c > > [ 4] .text.f0 PROGBITS 0000000000000000 000040 000009 00 AX 0 0 1 > ### No W flag > ### One __patchable_function_entries instead of 3. > [ 5] __patchable_function_entries PROGBITS 0000000000000000 000049 000018 00 A 0 0 1 > [ 6] .rela__patchable_function_entries RELA 0000000000000000 000280 000048 18 I 13 5 8 > [ 7] .text.f1 PROGBITS 0000000000000000 000061 000009 00 AX 0 0 1 > [ 8] .text.f2 PROGBITS 0000000000000000 00006a 000009 00 AX 0 0 1 Emitting a __patchable_function_entries for each function may waste object file sizes (64 bytes per function on ELF64). If zeros are allowed, emitting a single __patchable_function_entries should be fine. If we do want to emit unique sections, the condition should be either -ffunction-sections or COMDAT is used.