From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 2B6BA3853558 for ; Wed, 8 Jun 2022 17:16:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B6BA3853558 Received: by mail-pf1-x42f.google.com with SMTP id w21so18933333pfc.0 for ; Wed, 08 Jun 2022 10:16:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pGzTfEUs9nmFvpkSFIuiIX4CA6ay8gsu/N4aSW+kmQs=; b=KwXj/2bEK2FeDqWv+YVXOQo76oCU0ZmIVzUZiQhGxuaUeLsm5sIB08NWMIIGLcX/t/ YLzIR5ZdpBI2nID6owCk5zm0Cfdf6MC0p3LTQWFFaoOA3ocT06fFnJ+KfmR03b7F4I67 Awt9TgjZ0vTqnghHUh4f5iHlXshKC+KpuOYfNLtbLKiLNl6PZ4Iddw8lLWnlsKaxhorh s2eL3Fx3nEHTQeeuxAVFazVLuP8NNlG5UsastficeAkFRxUUE4jaPGhJi4kh1CAC+Grz w86+PgMyX9xugIqxt3aE7JLv/22V627o/AWIWkkCwbl0oy3CZq27MF7oLvcGhS25EvTa riew== X-Gm-Message-State: AOAM530BiWp1y5yrJq6dR/tYfXPzTXYyCkFaN5dXrQeJlW9qAt6nW1l1 zifu057644mT//OeOQsvvNrVJFpvvBHchA== X-Google-Smtp-Source: ABdhPJzvf7wDx70jc5Cy0bl8/s81XAqqvnf14zbBOHNNXubrmT9xQFrJiwQNIK7vZ/Ykc6Vxd0hyjw== X-Received: by 2002:a05:6a00:814:b0:51c:1878:4943 with SMTP id m20-20020a056a00081400b0051c18784943mr17127728pfk.62.1654708607977; Wed, 08 Jun 2022 10:16:47 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:dfe:1f0f:4f14:c886]) by smtp.gmail.com with ESMTPSA id v63-20020a638942000000b003fd12b703e5sm11561299pgd.49.2022.06.08.10.16.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 10:16:47 -0700 (PDT) Date: Wed, 8 Jun 2022 10:16:43 -0700 From: Fangrui Song To: Szabolcs Nagy Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v3] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA Message-ID: <20220608171643.k55emgjpvt5hxcwp@google.com> References: <20220601175633.2407189-1-maskray@google.com> <20220607174917.56nvyqg7f5ish5ii@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-21.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 08 Jun 2022 17:16:51 -0000 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.