From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31828 invoked from network); 1 May 2022 16:59:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 May 2022 16:59:22 -0000 Received: (qmail 23896 invoked by uid 550); 1 May 2022 16:59:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23864 invoked from network); 1 May 2022 16:59:17 -0000 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vAlb2JBNb7WaQvymu6M+dbpDk0Abaqo0nHL57cdfNTQ=; b=vcKiGAWbk+oFyOMuFDfnhOjSUAz2BmacVA98QNrlf8mIcf8OgB+Wve2GPHJiIZRIUF CWGv7gVdnFuVtGbpQb0YW23K3ixCPf/F3jzYGdN16x7vuzrf8vHRl72FXuPRDLo89Rr3 BBnIqerFiTj9DxjFdu6B3bnOcAy8kTAtqq6mhQDYkBBet/VIHn+g8neq1T1Kil68FBuF m0SqZ222qq0xWdGYm98CJ71zxIvH8EWMZY+7HJ2voXtbGZTMMLD7vU1pOljr1t+xDdMj vJq+HLRZoV69moY0A15999gpFEhaOdCzAJQ6do8jAUwcC3vEldO7NkJycRFvpfdfP04N 0fbw== X-Gm-Message-State: AOAM533nlRaMSGQ9IcOSds4wWj5XdpVfLFpcjeovvedXTpLKzYMk/O2j b4W1gJuDU1Cu9I1yuixDfUs92Ce11Rs= X-Google-Smtp-Source: ABdhPJyxdb5WrDWckP272MSCQ8Er6gu4qHQRxCVlrSWzkQXTsqjBhRbPqB0IrpUL79HhNtWoI3Zupw== X-Received: by 2002:a63:5041:0:b0:3c2:1938:3925 with SMTP id q1-20020a635041000000b003c219383925mr1013313pgl.555.1651424343359; Sun, 01 May 2022 09:59:03 -0700 (PDT) Date: Sun, 1 May 2022 09:59:02 -0700 From: Fangrui Song To: musl@lists.openwall.com Message-ID: <20220501165902.owup2lvij54yrmyg@gmail.com> References: <20220328153707.GE7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Subject: Re: [musl] How to support symbol versioning for musl? On 2022-04-25, Yang Zhonghua wrote: >Hi guys, > > >I tried to use the "versym" member of "struct dso", referring to the function "checkver()" of src/internal/vdso.c file. > > >prerequisites: >defining three versions for one symbol. > > >questions: >As "dso->strings + dso->syms[i].st_name" of the three symbols was the same name, I tried to use "dso->versym[i]" to distinguish versions. But only the default symbol version was a positive value, the others were both negative values(-32766). > > >Is there any way to get the right "dso->versym[i]" value for all symbol versions? >Looking forward to your valuable advice. Thank you so much! > > >Yang Zhonghua You may want to switch posting style https://www.idallen.com/topposting.html (Top-posting vs Bottom-posting) to match others. I have a write-up about glibc rtld behavior (also FreeBSD rtld-elf's) at https://maskray.me/blog/2020-11-26-all-about-symbol-versioning#rtld-behavior Paste the most relevant part below: When searching a definition for `foo`, * for an object without symbol versioning + it can be bound to `foo` * for an object with symbol versioning + it can be bound to `foo` of version `VER_NDX_GLOBAL`. This takes precendence over the next two rules + it can be bound to `foo` of any default version + it can be bound to `foo` of non-default version index 2 in relocation resolving phase (not dlvsym). The rule retains compatibility when a shared object becomes versioned. When searching a definition for `foo@v1`, * for an object without symbol versioning + it can be bound to `foo` * for an object with symbol versioning + it can be bound to `foo@v1` or `foo@@v1` + it can be bound to `foo` of version `VER_NDX_GLOBAL` in relocation resolving phase (not dlvsym)