[PATCH v3] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA

[Szabolcs Nagy]

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.