public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Peter O'Connor" <sunnyflunk@serpentos.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: libc-alpha@sourceware.org, Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH v4 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support
Date: Wed, 2 Mar 2022 10:42:05 +1100	[thread overview]
Message-ID: <CAE7oKpHvZfRJXSret6+kLEVAGsEf4XWHD2XpcZfmkPOs_K22UA@mail.gmail.com> (raw)
In-Reply-To: <20220301161706.185216-4-hjl.tools@gmail.com>

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
<libc-alpha@sourceware.org> 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

  parent reply	other threads:[~2022-03-01 23:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 16:17 [PATCH v4 0/5] Support DT_RELR relative relocation format H.J. Lu
2022-03-01 16:17 ` [PATCH v4 1/5] elf: Support DT_RELR relative relocation format [BZ #27924] H.J. Lu
2022-03-01 16:17 ` [PATCH v4 2/5] elf: Properly handle zero DT_RELA/DT_REL values H.J. Lu
2022-03-01 19:15   ` Fangrui Song
2022-03-01 16:17 ` [PATCH v4 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support H.J. Lu
2022-03-01 19:31   ` Fangrui Song
2022-03-01 22:33     ` H.J. Lu
2022-03-01 22:46       ` Fangrui Song
2022-03-01 22:56         ` H.J. Lu
2022-03-01 23:42   ` Peter O'Connor [this message]
2022-03-01 16:17 ` [PATCH v4 4/5] Add --disable-default-dt-relr H.J. Lu
2022-03-01 16:17 ` [PATCH v4 5/5] NEWS: Mention DT_RELR support H.J. Lu
2022-03-01 19:21   ` Fangrui Song
2022-03-01 22:37     ` H.J. Lu
2022-03-01 22:38       ` Fāng-ruì Sòng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE7oKpHvZfRJXSret6+kLEVAGsEf4XWHD2XpcZfmkPOs_K22UA@mail.gmail.com \
    --to=sunnyflunk@serpentos.com \
    --cc=hjl.tools@gmail.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).