From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by sourceware.org (Postfix) with ESMTPS id 8EFEF3858425 for ; Fri, 12 May 2023 14:07:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8EFEF3858425 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E089D65705 for ; Fri, 12 May 2023 14:07:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EA68C433A0 for ; Fri, 12 May 2023 14:07:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683900457; bh=BuBZ0NKPv4b5TTHt/yXDeKwM+N44jCkxHlTtGNJBAps=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=APiaucasUgBzeFCyJMczW91D9XCMokcWqxdErF8/Z/lAG1LRanuHZpGYppN3OQ3sk ox1Xdlpgn0S6P6HNj8G3jnWg/rgqO3w5UI8zb6O/8W2Te/TZAtlxDxAraY5LiTmwCF mvV+foF5/t8I7PG7CAuoRNx2ni6f6ThyCZz6lzdhHeuAL21TT0iLzyfPFhEUmNqYVT 3TdkEVu7hRrDYgfBtzu1Zq1Fa1ENGGSr5EstMy8h+8mYUI3SOk5HkeN/uItBZcIzmB epZdocyyqeVMaEEF6JjPA3U/IVYmkoV/jc/Tmh1KFfV2FU61rio8wdfZefRZP2R9rj nN+eJVt28oN5g== Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-4f139de8cefso52389619e87.0 for ; Fri, 12 May 2023 07:07:37 -0700 (PDT) X-Gm-Message-State: AC+VfDyB4RfpHQxKHCEzHFYFe6cNOFnoHPQ2OTwrurDuXCzZ9tyRmqej pM3rzOu/ARr1YpfCGrMjZMXMRQ6hvWez/yyAmzs= X-Google-Smtp-Source: ACHHUZ4ZCa0KwIH0EctfOiM/Yh0eZ7vGkYGEvRlf+GPqOtiPLovaegDlR5zOgigzFh3Ii9M40YMxHcgvWb/12Lgq39g= X-Received: by 2002:ac2:59cc:0:b0:4f0:13e3:a291 with SMTP id x12-20020ac259cc000000b004f013e3a291mr3327133lfn.28.1683900455217; Fri, 12 May 2023 07:07:35 -0700 (PDT) MIME-Version: 1.0 References: <20230509085835.1143661-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Fri, 12 May 2023 16:07:23 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] i386: Honour -mdirect-extern-access when calling __fentry__ To: Uros Bizjak Cc: "H.J. Lu" , gcc-patches@gcc.gnu.org, keescook@chromium.org, Jakub Jelinek , Richard Biener , Hou Wenlong Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 11 May 2023 at 08:08, Uros Bizjak wrote: > > On Thu, May 11, 2023 at 12:04=E2=80=AFAM H.J. Lu wr= ote: > > > > On Wed, May 10, 2023 at 2:17=E2=80=AFAM Uros Bizjak = wrote: > > > > > > On Tue, May 9, 2023 at 10:58=E2=80=AFAM Ard Biesheuvel wrote: > > > > > > > > The small and medium PIC code models generate profiling calls that > > > > always load the address of __fentry__() via the GOT, even if > > > > -mdirect-extern-access is in effect. > > > > > > > > This deviates from the behavior with respect to other external > > > > references, and results in a longer opcode that relies on linker > > > > relaxation to eliminate the GOT load. In this particular case, the > > > > transformation replaces an indirect 'CALL *__fentry__@GOTPCREL(%rip= )' > > > > with either 'CALL __fentry__; NOP' or 'NOP; CALL __fentry__', where= the > > > > NOP is a 1 byte NOP that preserves the 6 byte length of the sequenc= e. > > > > > > > > This is problematic for the Linux kernel, which generally relies on > > > > -mdirect-extern-access and hidden visibility to eliminate GOT based > > > > symbol references in code generated with -fpie/-fpic, without havin= g to > > > > depend on linker relaxation. > > > > > > > > The Linux kernel relies on code patching to replace these opcodes w= ith > > > > NOPs at runtime, and this is complicated code that we'd prefer not = to > > > > complicate even more by adding support for patching both 5 and 6 by= te > > > > sequences as well as parsing the instruction stream to decide which > > > > variant of CALL+NOP we are dealing with. > > > > > > > > So let's honour -mdirect-extern-access, and only load the address o= f > > > > __fentry__ via the GOT if direct references to external symbols are= not > > > > permitted. > > > > > > > > Note that the GOT reference in question is in fact a data reference= : we > > > > explicitly load the address of __fentry__ from the GOT, which amoun= ts to > > > > eager binding, rather than emitting a PLT call that could bind eage= rly, > > > > lazily or directly at link time. > > > > > > > > gcc/ChangeLog: > > > > > > > > * config/i386/i386.cc (x86_function_profiler): Take > > > > ix86_direct_extern_access into account when generating ca= lls > > > > to __fentry__() > > > > > > HJ, is the patch OK with you? > > > > LGTM. > > OK then. > Thanks all. Is anything expected of me at this point?