From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 7B981385DC1D for ; Wed, 25 May 2022 20:10:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B981385DC1D Received: by mail-pl1-x630.google.com with SMTP id a13so8984309plh.6 for ; Wed, 25 May 2022 13:10:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=EWKHXCBv44b/7tfXWBm5YkT56hkZYRx/AyWizOY8Y+I=; b=0WwHpg3edMKOfnPhMDc+ahTGQXtayXwRA0waV/9a62MlrMJsD7loxFPDzmojF/J/67 FnY15QoxJz9dNmPuJbriej22rlOKWdjUl1muEv9fEmYTdx027EI6jPkPGhav0trfL14q b8kTuNYED0fqIoul4HeUc4Gd+XDprSJyrCYMUZhuhEuNgrzS1JAGQHJkBtW6uNMr7Zfr 0shskBZvppcWKzk2dPn7a22NuoT1MCn5tiJI3pwKDHu9ylf/5GokeRgcfoILcIZJENg3 AM0jTSk8vcu9I2fF4nBRsm0J6rmopDatQ435vpqGT7XMRTAHaOZdbwDl4b+Erl4+eql9 GdlQ== X-Gm-Message-State: AOAM531nXCEaaS6hf6oLQSpW0Apz7X7hAW8UvePYO8SO/McBrj7CkE0v xy3DBMbN4Aqw7lGzGSocNHwYiII4Vpi3Fg== X-Google-Smtp-Source: ABdhPJx5QqclRgCsr/b7LIVMSCtAyc/vXQqd0A0PrwwwqHmLUwydwfPFy2LLQpog0u0Qox0PmM9w3g== X-Received: by 2002:a17:902:ef45:b0:155:cede:5a9d with SMTP id e5-20020a170902ef4500b00155cede5a9dmr33994058plx.93.1653509431311; Wed, 25 May 2022 13:10:31 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:84dd:75b4:f155:aebd]) by smtp.gmail.com with ESMTPSA id o2-20020a170902d4c200b0016168e90f2csm9853397plg.208.2022.05.25.13.10.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 May 2022 13:10:30 -0700 (PDT) Date: Wed, 25 May 2022 13:10:27 -0700 From: "maskray@google.com" To: Wilco Dijkstra Cc: "H.J. Lu" , Szabolcs Nagy , GNU C Library Subject: Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" Message-ID: <20220525201027.wp2hzm4babdzqj6u@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 20:10:34 -0000 On 2022-05-25, Wilco Dijkstra wrote: >Hi H.J., > >> All imported symbols can be marked with the default visibility and all >> exported symbols, in both executables and shared libraries, can be >> marked with the protected visibility.   These require code changes. > >I meant doing this automatically using an option so most code requires no >source changes. If commonly used libraries mark their exported symbols, >most code (PIC, PIE and non-PIE) could be compiled using this option and >produce efficient code without copy relocations and only using GOT >indirections when needed (ie. accessing an exported symbol in another .so). >It would also imply -fno-semantic-interposition for non-exported symbols. >Currently there is no way to achieve this using options (eg. -fvisibility only >affects definitions), and LLVM and GCC disagree on many details. > >Cheers, >Wilco Working out-of-the-box with -fpic and -fpie is trivial. Working out-of-the-box with -fno-pic is not, as some code may rely on the traditional codegen behavior that absolute resolutions are used. I think the situation is worse on x86-32. For protected data symbols, it's not a problem: (a) Exported data symbols from shared object are rare. This is discouraged as exported data symbols is part of ABI and makes DSO upgrading difficult. (b) Making exported data symbols exported is even rarer. (c) In addition, many aarch64 OSes (Android, Chrome OS, FreeBSD, some musl+llvm based Linux distributions, etc) use lld which does not allow copy relocation on protected data symbols. I haven't heard they have found any breakage due to the lld linker error. (d) -fno-pic is out of favor now with the adoption of default -fpie.