public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Fangrui Song <maskray@google.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v3] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
Date: Thu, 9 Jun 2022 09:12:54 +0100	[thread overview]
Message-ID: <YqGrhuh/Bjf2RxHi@arm.com> (raw)
In-Reply-To: <20220608171643.k55emgjpvt5hxcwp@google.com>

The 06/08/2022 10:16, Fangrui Song wrote:
> On 2022-06-08, Szabolcs Nagy wrote:
> > The 06/07/2022 10:49, Fangrui Song wrote:
> > > On 2022-06-07, Szabolcs Nagy wrote:
> > > > > -  int protected = (*ref
> > > > > -		   && ELFW(ST_VISIBILITY) ((*ref)->st_other) == STV_PROTECTED);
> > > > > -  if (__glibc_unlikely (protected != 0))
> > > > > -    {
> > > > > -      /* It is very tricky.  We need to figure out what value to
> > > > > -	 return for the protected symbol.  */
> > > > > -      if (type_class == ELF_RTYPE_CLASS_PLT)
> > > > > -	{
> > > > > -	  if (current_value.s != NULL && current_value.m != undef_map)
> > > > > -	    {
> > > > > -	      current_value.s = *ref;
> > > > > -	      current_value.m = undef_map;
> > > > > -	    }
> > > > > -	}
> > > > > -      else
> > > > > -	{
> > > > > -	  struct sym_val protected_value = { NULL, NULL };
> > > > > -
> > > > > -	  for (scope = symbol_scope; *scope != NULL; i = 0, ++scope)
> > > > > -	    if (do_lookup_x (undef_name, new_hash, &old_hash, *ref,
> > > > > -			     &protected_value, *scope, i, version, flags,
> > > > > -			     skip_map,
> > > > > -			     (ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
> > > > > -			      && ELFW(ST_TYPE) ((*ref)->st_info) == STT_OBJECT
> > > > > -			      && type_class == ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA)
> > > > > -			     ? ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
> > > > > -			     : ELF_RTYPE_CLASS_PLT, NULL) != 0)
> > > > > -	      break;
> > > > > -
> > > > > -	  if (protected_value.s != NULL && protected_value.m != undef_map)
> > > > > -	    {
> > > > > -	      current_value.s = *ref;
> > > > > -	      current_value.m = undef_map;
> > > > > -	    }
> > > > > -	}
> > > > > -    }
> > > > > -
> > > >
> > > > i think we should keep this part without the
> > > > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit.
> > > 
> > > I have played a bit but do not find any difference (with some examples using
> > > "canonical PLT entries") if I simply remove the whole if statement.  Do you
> > > find anything I may have missed?
> > 
> > yes, i posted an example earlier that behaves differently.
> 
> OK. You meant the
> https://sourceware.org/pipermail/libc-alpha/2022-May/139183.html
> example with GNU ld as the linker.
> 
> With lld the behavior is the same with or without the code block.

well you need GOT reloc, obviously if lld locally binds
the symbol then there will be no interpositon.

but we must support GOT relocs for protected symbols,
that's perfectly valid (even if no linker generates it).

> 
> > object symbol defined in exe and dso, the dso one is protected
> > and has a GOT reloc for it.
> > 
> > with the extra logic the GOT is resolved to the definition in
> > the dso, without it the exe interposes the protected symbol.
> 
> Created
> https://sourceware.org/pipermail/libc-alpha/2022-June/139574.html
> I'd still wish that the code block is removed, but we can do that later.
> I assume that once one port of GNU ld stops producing GLOB_DAT for
> protected symbol, we can drop the code block for that port.

thanks.

  reply	other threads:[~2022-06-09  8:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01  4:50 [PATCH v2] " Fangrui Song
2022-06-01  7:26 ` Szabolcs Nagy
2022-06-01  7:34   ` Fangrui Song
2022-06-01  9:53     ` Szabolcs Nagy
2022-06-01 10:56       ` Florian Weimer
2022-06-02  5:21         ` Fangrui Song
2022-06-01 17:56       ` [PATCH v3] " Fangrui Song
2022-06-07 13:24         ` Szabolcs Nagy
2022-06-07 17:49           ` Fangrui Song
2022-06-08  9:15             ` Szabolcs Nagy
2022-06-08 17:16               ` Fangrui Song
2022-06-09  8:12                 ` Szabolcs Nagy [this message]
2022-06-07 17:49           ` H.J. Lu
2022-06-07 18:21             ` Fangrui Song
2022-06-07 19:21               ` H.J. Lu
2022-06-07 20:00                 ` Fangrui Song
2022-06-07 21:02                   ` H.J. Lu
2022-06-07 23:57                     ` Fangrui Song
2022-06-08  1:51                       ` H.J. Lu
2022-06-08  3:42                         ` Fangrui Song

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=YqGrhuh/Bjf2RxHi@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=maskray@google.com \
    /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).