Re: [PATCH v3] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA

[Fangrui Song <maskray@google.com>]

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.

>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.