From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 345F13857825 for ; Wed, 25 May 2022 20:45:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 345F13857825 Received: by mail-pj1-x1034.google.com with SMTP id gk22so2311118pjb.1 for ; Wed, 25 May 2022 13:45:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+q84x2G/9SSzLgHl+NijzzgJtzdOrvzoE+ChuV+BJp4=; b=de9ukln0oubatZc5DxJxK4xwpQqTVmRXIG0FrlteLoVZGilZW6y/krFIQXFNybaw3s 26yKQoPUxYGmCF3LedJI8DMbl9YO3s8r9rde8+Me67ILxgLEJ83Cd3gO/oNbVGgJ7jk/ rV+mq7PlnKq0e69BEASbph+QBPE4pf89dpb57Se8IpdH8E7IW2t+2C89JW+yqdXMpKhK jfzs4janoK8VKAl35BHAQQKQ7J889sSTlCVpI75qjqHNOdaeAaHcJ9h5q0jqDuI/Qwaq 2ecz2/5VflLJ2jrhA+1RwJDMqJnwq8S4MjWfJhQNCALBl1rh+ZIF5LWbM3zlm5EolsJW CRWQ== X-Gm-Message-State: AOAM531+jCfy0vx4ZBrquDXmqIxKiSrICPLnE2dmkspAcUV9Z7d49PYv 14Fn0ohCYPgMkS7ugi9Et6dSVVp+ditH8E7H0R4Hjiplit0= X-Google-Smtp-Source: ABdhPJwe15UR1fgqWXhZSiOi0SKhvhts63S9sUqIeBWG/lUwjLBt3F27AwAX27tmardXPbF3n9KvoMeK0HhyQNKx29g= X-Received: by 2002:a17:90b:314e:b0:1dc:d143:a15d with SMTP id ip14-20020a17090b314e00b001dcd143a15dmr12365507pjb.111.1653511516107; Wed, 25 May 2022 13:45:16 -0700 (PDT) MIME-Version: 1.0 References: <87mtf5wk0k.fsf@oldenburg.str.redhat.com> In-Reply-To: <87mtf5wk0k.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Wed, 25 May 2022 13:44:40 -0700 Message-ID: Subject: Re: [PATCH 2/3] Revert "[AArch64][BZ #17711] Fix extern protected data handling" To: Florian Weimer Cc: Wilco Dijkstra via Libc-alpha , Wilco Dijkstra , Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3019.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 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:45:19 -0000 On Wed, May 25, 2022 at 11:21 AM Florian Weimer wrote: > > * Wilco Dijkstra via Libc-alpha: > > > 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, "export" describes what happens to a symbol at the library build time. An exported symbol can be imported to a library user. Without LTO, compilers can't tell if an external symbol will be imported or exported. > > 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. > > What about -flto (with a linker plugin)? > LTO certainly works. An undefined symbol will be imported from a shared library. -- H.J.