From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 5A6163857C63 for ; Sat, 13 Mar 2021 06:53:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5A6163857C63 Received: by mail-pg1-x534.google.com with SMTP id n9so16328760pgi.7 for ; Fri, 12 Mar 2021 22:53:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jfhQLnxsEy+3shxzjgeoYnIQoABioB/fqNkf2/4n4VA=; b=Eux+u6Mv55MF41jspIz2B8FAEKCxwyiY/KYoar7atOmez3iNVCLra56u49q8tAJqzL 4R3gJQ/REDgbSsbmNHXP9mNaCc3nSZnMyF0G59yaJp2gQOSpA9qhQOErPUGqqzAO9QJe rFzzBeShBvgl0bzhxCh2LYrWylZWuA/m+riLiWKgOEJbM/RDqdjqqnatmWCIwUBf/mkk deAqN7RM8yZjKAnUsJiyOOjVqi+zlmGBoFHyt4LcAn0krXnDKh5OrT/ygqOn4A3zcfy7 kUIzZ5/G3kjwJ/woze34PlQNLDLKseH4DdPD8/sm4W4DI2do//VGGwBJm/ydgur6cd3O YwzQ== X-Gm-Message-State: AOAM530N85RThY5/Zr1URM3qTOz19Gn1Aftyc6qTNGhkm7JqzPOVSL4S 9Y/ZZtcTairSVWsR6BEdG6P4/JFD8VCT7c1S0b18HYl3 X-Google-Smtp-Source: ABdhPJyGF8TmtbQCsozZLXf5F/w243INJmGtfJ8dIWBMIIZwwG34iRmt53KbZgOQjqe0qx5Oqb03XLLUe48JTz/0a20= X-Received: by 2002:a63:e203:: with SMTP id q3mr15320494pgh.325.1615618430000; Fri, 12 Mar 2021 22:53:50 -0800 (PST) MIME-Version: 1.0 References: <87a6r87il4.fsf@oldenburg.str.redhat.com> <87sg505zy0.fsf@oldenburg.str.redhat.com> <87im5w4av2.fsf@oldenburg.str.redhat.com> In-Reply-To: <87im5w4av2.fsf@oldenburg.str.redhat.com> From: Alessandro Carminati Date: Sat, 13 Mar 2021 07:53:38 +0100 Message-ID: Subject: Re: Fwd: MIPSEL GLIBC sem_init() not shared To: libc-help@sourceware.org X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 06:53:52 -0000 On Fri, Mar 12, 2021 at 5:04 PM Florian Weimer wrote: > > * Alessandro Carminati via Libc-help: > > > Al the sources I have found seems to agree on the fact that if a > > symbol is unversioned, like in my case, the symbol the dynamic linker > > should use is the one that carries the "@@" > > I think they talk about the link editor (static linker) chosing the > symbol version, and not about what happens at run time. Thank you for your explanation. I want you to know my appreciation for your contribution. Back to the topic; about your last statement, I'm quite confused. For example, if the target of the double @@ feature is the static linker, why they talk about it in a post where the topic is DSO? Why this double @@ is mainteined inside the DSOs? Reflecting on my scenario I see that the dynamic linker finds quite unusual situation where the symbol is required and there's no dependency on the DSO containing it, and no indication (.gnu.version_r) about how to handle it. My assumption was that the double @@ would handle these situation, but it is reasonable that this situation to have another handling. For this reason my current understanding is that the dynamic linker would use default the double @@ indicated function, where the .gnu.version_r is present but not populated, and use the older symbol where the .gnu.version_r is missing. This way it would handle correctly the situation where old executables do not have the section because it didn't exist yet. I will check the dynamic linker source code to confute or confirm this hypothesis. Thanks Alessandro