From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 9E66D3850401 for ; Fri, 8 Jan 2021 02:07:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9E66D3850401 Received: by mail-oi1-x22f.google.com with SMTP id 9so9750718oiq.3 for ; Thu, 07 Jan 2021 18:07:58 -0800 (PST) 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:cc; bh=w6ciR2X0GRv2m8KaYtM2u5mFS/5jMlfJBfYQzIQRJ0I=; b=n4QdL/7IA8F3Hdm0lcLRZPThnSwV+LXgjzrBexJ4J5CJAY566xM61u2jVNxu7+zqQK 4ZHQQvGXjkBgc0zX/gGlVJ70ahF2Tc344gOMAPoNvZddkC/TQAXjmQKx3mwZWfZgGM5U X8xy3lWKM3vZO6R9CDvgzOMBVwzbkVHtJ8UMktezW7GHtBjk6atxmtlPSamc9OkpiP9B zyKPvF16CAy4yMf+3Es3cvty/jjW9hZsDPL6pM5/wi37Eu+98iO6o92IQrRufrS3ctMJ QCM4dzqgjTy7K9HurnrtJkvywCnqcy0CnOfWXKqmLP0dI58Bt+UpaxOZ9efYH/rVdd72 CyWQ== X-Gm-Message-State: AOAM530hYnJ/rlBhBFfnUYN9ZqYndbgS8cLkPIT1cIaabvK2YYsxzQ84 nVR2RkqlpioxqYcJCavUFjWJfFTnjy33uhDmVv8vA8ZiTTc= X-Google-Smtp-Source: ABdhPJwMzMBi2Awbr6HQ93qwuzGVPnHHeQPwnlGj/tNC6nVbwNvx+6j5PvbwRZRXA5Vxi1vaGk1igVRgJ2oGi8/4GEw= X-Received: by 2002:aca:f5d3:: with SMTP id t202mr989996oih.25.1610071678033; Thu, 07 Jan 2021 18:07:58 -0800 (PST) MIME-Version: 1.0 References: <20201217071017.xylpud62keerb54u@gmail.com> <87h7o81t3v.fsf@mid.deneb.enyo.de> In-Reply-To: From: "H.J. Lu" Date: Thu, 7 Jan 2021 18:07:21 -0800 Message-ID: Subject: Re: Add -fdirect-access-external-data To: Fangrui Song Cc: GCC Development , Florian Weimer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, 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: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 02:08:00 -0000 On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote: > > On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote: > > > > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote: > > > > > > * Fangrui Song: > > > > > > > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which > > > > proposes -fdirect-access-external-data to address some x86-64 > > > > GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1] > > > > it can prevent copy relocations). > > > > > > > > [1] Mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112#c2 > > > > > > > > Since I am going to add this option to Clang and I hope (once GCC decides to > > > > implement this option the two compilers can use the same option name), I bring > > > > it to your attention. > > > > > > One worry I have is that people start building shared objects with > > > direct data access, expecting the main program to be built with > > > indirect access. We already see this today with Qt. It's not really > > > supported well by the toolchain and causes frequent issues. > > > > It can be solved by ABI extension implemented in linker, ld.so and > > compiler. > > > > > Depending on the ELF ABI in question, the new pair of -f options might > > > not actually be meaningful. It really depends on whether you have > > > reasonably-sized displacements available. I think there are some ABIs > > > where the optimization is theoretically possible, but impractical > > > because the ilimit it imposes on data segment (think AArch64 without > > > adrp). > > > > > > > > -- > > H.J. > > Please check out new comments on > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 > > -fdirect-access-external-data is still the best name. The option is > useful to avoid copy relocations / "canonical PLT entry" > (st_shndx=0,st_value!=0) in -fno-pic code. > I will proceed with my Clang patch. If I understand it correctly, you want to treat all accesses to protected definitions as local access and all read/write accesses to undefined symbols should go through GOT. Branches to undefined symbols can use PLT. -fdirect-access-external-data doesn't reflect it. -- H.J.