From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 43C053858D37 for ; Tue, 1 Mar 2022 23:42:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 43C053858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=serpentos.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=serpentos.com Received: by mail-ot1-x334.google.com with SMTP id g6-20020a9d6486000000b005acf9a0b644so158931otl.12 for ; Tue, 01 Mar 2022 15:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=serpentos-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lhn3AACIEJOGgCZpmUDlDDDt4G+KDbrx3o/ajf05Yyg=; b=zEw8rOMOqog52jCM0YOCRJN1yBdQv/7sZw7DbOwPHwuqP1Req32kP7QmcagErXHlD5 4E+ZubYoQUHTYPkMfM8g75VwT0Zim55vR5y6hn4l3K5WtCs3CFndfWQow5aZexeGTb7l C2TH0NHqRpe3lK7vSVKWcb95Bs3GEn+BTGGYNxnRrnK2TsI24dmGwonnduZaI+cuPFvY QPtafsxokLo2H8gVGA22oB63vJtOv7RzzeeomRWX1ojCVotjDUl3YELkQSDm//PL46Wz hDt74DUbRxkZgFXViLg2cpUcOhqW4bMxzkOzch/M/MWXSzh8+Dc7qeDnkGY7kBNpbjv0 oP7w== 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=Lhn3AACIEJOGgCZpmUDlDDDt4G+KDbrx3o/ajf05Yyg=; b=OQ6M1JD+LBkC5X9akwwWrjR+xrmwiD4xc7XxHxOlu6zLg+uZujsITUDdLohdaBnkky Q7pWGZyYgbC7tervkS46pMJTDKeoYj5uvU8EkMa1SEnKAK4aVxzTM+8W6NW5NY9jCkh8 aj687mNleuk3opGgUXwOhsoODb171Xjrmr5FlwcU1EAd5xgD5pTZNR5s2FTCRpCNzuTK BgiVeknTo1Jtr2MtByCyRs/Bi3/ndYzqLKp5Qnj+JT2X+YCk0r0S6dbjd+xvzunN829o ImC71kJ1V2/4jpjvzSDqSYzUDfDI5hf1/ffzel1EGczjEUOE3E6Gn/3qdwXtkLE0gpS+ AcNQ== X-Gm-Message-State: AOAM532+v3Ouxkl539m1D/G17YZMA5taFDGyQIqr5VlOFQ9KM3S1UKSx zMzyCTbUYLzn8o8qoZmmIGfGK2Ve8wgq3rlBIl6tqw== X-Google-Smtp-Source: ABdhPJxPoSRJ2hU97clce04LTDkHWOr0a3VpcZGBrYbdf/29JCYdWHSdygeGItE2hQFCbCgK6aF4QbzmCqmHwFm7t/k= X-Received: by 2002:a05:6830:1db0:b0:5af:22a6:e97d with SMTP id z16-20020a0568301db000b005af22a6e97dmr14117820oti.288.1646178136626; Tue, 01 Mar 2022 15:42:16 -0800 (PST) MIME-Version: 1.0 References: <20220301161706.185216-1-hjl.tools@gmail.com> <20220301161706.185216-4-hjl.tools@gmail.com> In-Reply-To: <20220301161706.185216-4-hjl.tools@gmail.com> From: "Peter O'Connor" Date: Wed, 2 Mar 2022 10:42:05 +1100 Message-ID: Subject: Re: [PATCH v4 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support To: "H.J. Lu" Cc: libc-alpha@sourceware.org, Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 01 Mar 2022 23:42:19 -0000 I've been testing out and using patches (1,2,4) for about 2-3 weeks and have now made it the default for all packages. The reason for excluding patch 3 (and reverted the relevant binutils patch) was due to the enforcement of GLIBC_ABI_DT_RELR as it was not supported by the LLD linker (with clang I use LLD). Other than the size benefits I was able to measure a 1.7s time reduction (about 1.5% of total) in the configure/build of gettext with clang (shared lib build), just from enabling RELR in the full LLVM stack (and not in any other package). Seems fairly significant given that loading clang would only be a portion of the total build time. On Wed, Mar 2, 2022 at 3:19 AM H.J. Lu via Libc-alpha wrote: > @@ -352,6 +370,17 @@ _dl_check_map_versions (struct link_map *map, int verbose, int trace_mode) > } > } > > + /* Issue an error if there is a DT_RELR entry without GLIBC_ABI_DT_RELR > + dependency nor GLIBC_PRIVATE definition. */ > + if (map->l_info[DT_RELR] != NULL > + && __glibc_unlikely (map->l_abi_version == lav_none)) > + { > + _dl_exception_create > + (&exception, DSO_FILENAME (map->l_name), > + N_("DT_RELR without GLIBC_ABI_DT_RELR dependency")); > + goto call_error; > + } > + > return result; > } > I have now retested this patch series with most of patch 3, but excluding this section (which would immediately break the container). As expected, no problems encountered. But it does make one wonder the value in making glibc refuse to load a library it is perfectly able to load, just because it lacks the GLIBC_ABI_DT_RELR dependency. There are four scenarios: Glibc without this series (<2.36): (1) RELR file without symbol - Fails to load (or crashes) without good error message (2) RELR file with symbol - Fails to load due to missing symbol (much clearer) Glibc with this series (2.36+): (3) RELR file without symbol - Refuses to load with "DT_RELR without GLIBC_ABI_DT_RELR dependency" message (4) RELR file with symbol - Loads and works fine The main driver of GLIBC_ABI_DT_RELR seemed to be to avoid 'time-travel' compatibility, essentially to avoid situation (1) where you have no idea why the file won't load. Once you have a glibc that includes the "DT_RELR without GLIBC_ABI_DT_RELR dependency" error, you also have support for RELR and the ability to load it. There's no time-travel issue in this case, but merely enforcing the requirement for all linkers wanting to support RELR to add the symbol for glibc. Peter