From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 5222E3858D39 for ; Wed, 8 Feb 2023 23:53:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5222E3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62b.google.com with SMTP id v23so1067093plo.1 for ; Wed, 08 Feb 2023 15:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bpWnisjePsxdwJjfVi3OFCx7CJ/QWYA6qVMsWKzNtw0=; b=NrSMMmtK8Cnczd5wOlqkzec8MKzKvL7q6e6f0zLRivPXac77jytFQKqKoyBBzfRX+1 VHyR3Byn22MuvEgGJ+hoj8sT5qKwP3kHkQdIfvctvNDjBrU7t8C006I555abNVgWeZi3 GnEE1cNO5D5/wHqjVeO0D6aCIzd6vITMYYnQxsjFS0/YxpZd2Jke+/cid7btdQVFsMX6 9kgUDmlnQGlzftrd53mQtbdQQ6GBRSGAN4ucLDXShBlk8HPJd6HARe4DO9K7yuMAPkAk aT+IRu1gcVWarfOMAs6rQS7betJXhyaPYoSA8xCyPr5JTYZgoyG8mu3DCw9PByrDLczc iCRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bpWnisjePsxdwJjfVi3OFCx7CJ/QWYA6qVMsWKzNtw0=; b=Xmu8mTJmn8FpzMy+ZE5VFztdJ7CUm9kDpfO8qhylIZydA7b4ZwXT8yvypsCK97TGuW CoENqAV4yGyHGnirZJ5G6QPDgFMldXUzQioz2eTKfUFrdXtG7wH/S2lnG5M0XUPF+bAl fg39POj8IOinMS6db4r8RderiydL9wDZ4pcdkX0+7UJs7mGYBkcl/eGJ6iVqUu+7oc5B GgQIil/VnuXy3MsSEZ2Fg29fMtcK20Fc5MJKnEY/mWM+mmDvig9cf4/gh1q/HEnEpKfh xC0s3lHetJo8DPGNw53Ob55iJBxxVQq9uP1Xe3HTGXOJYWclu/tYxkWEH1BesnuLoBnm djTA== X-Gm-Message-State: AO0yUKVPBHZL8pjV+0sRIGf2zUZzHCHNxPgxxgDaz1hyc62zP61nZZLw Os8wjSNITLGWnGVJMXEmq1RNpWfetOh9doUI4SENunjt X-Google-Smtp-Source: AK7set9kHMJ34ymXiOEn+X13XJH3Ph0R5lI7hyh3dbYSR3C5g8GWVmwiF9pCMLyza+ZLjkhjxmA1cdbkQF5y/s8FaFI= X-Received: by 2002:a17:90a:fe0d:b0:22c:387f:67b1 with SMTP id ck13-20020a17090afe0d00b0022c387f67b1mr1051840pjb.101.1675900396176; Wed, 08 Feb 2023 15:53:16 -0800 (PST) MIME-Version: 1.0 References: <6cd03b30-a40b-5e29-094a-6a4529852633@oracle.com> In-Reply-To: <6cd03b30-a40b-5e29-094a-6a4529852633@oracle.com> From: Cary Coutant Date: Wed, 8 Feb 2023 15:53:04 -0800 Message-ID: Subject: Re: About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold To: Vladimir Mezentsev Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > I prepared a small test that demonstrates the problem: > > % cat test.c > void *dlopen (const char *pathname, int mode) > { return (void *) 0; } > > __attribute__ ((__symver__ ("dlopen@GLIBC_2.1"))) > void *__collector_dlopen_2_1 (const char *pathname, int mode) > { return (void *) 0; } > > __attribute__ ((__symver__ ("dlopen@GLIBC_2.0"))) > void *__collector_dlopen_2_0 (const char *pathname, int mode) > { return (void *) 0; } > > int main() > { return 0; } The unbound copy of dlopen is the problem here. If you want a default version, you should use a symver attribute with an "@@" on that copy. > % cat map.txt > GLIBC_2.0 { > global: > dlopen; > }; > > GLIBC_2.1 { > global: > dlopen; > }; Normally, I'd expect the GLIBC_2.1 { ... } block to include all of GLIBC_2.0, by naming the previous version after the closing brace. This is irrelevant to this problem, but you might want to think about that. > There are no problems with -fuse-ld=bfd: > % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script > -Wl,map.txt -fuse-ld=bfd You should also use -Wl,-E here. Otherwise, the symbols will not be exported to the dynamic symbol table. > The output of `nm` shows exactly what I expected: > % nm a.out | grep dlopen > 08049191 T __collector_dlopen_2_0 > 08049187 T __collector_dlopen_2_1 > 0804917d t dlopen > 08049191 t dlopen@GLIBC_2.0 > 08049187 t dlopen@GLIBC_2.1 Here, you're just dumping the static symbol table. Use "nm -D" to dump the dynamic symbol table, which is what you're really interested in. > But with -fuse-ld=gold: > % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script > -Wl,map.txt -fuse-ld=gold > /bin/ld.gold: warning: /tmp/cc6YCOol.o: unknown program property type > 0xc0010001 in .note.gnu.property section > /bin/ld.gold: warning: using 'GLIBC_2.0' as version for 'dlopen' which > is also named in version 'GLIBC_2.1' in script > /bin/ld.gold: error: /tmp/cc6YCOol.o: multiple definition of 'dlopen' > /bin/ld.gold: /tmp/cc6YCOol.o: previous definition here > collect2: error: ld returned 1 exit status If you leave out the unbound version of dlopen, or symver it to a third version node, this should work. > My questions: > > Is my test correct ? Sorry, I really don't know. The ld manual doesn't really cover this case, nor do any of the ld test cases that I could find. BFD ld and gold differ here, and I don't know whether or not to consider that a bug. > if not: > we need to interpose the dlopen functions from libdl.so. > How can I do it correctly ? If you bind every version of dlopen to a different version node, it should work in both linkers. > If yes: > Is this a known compiler bug in gold ? If not, do I need to create one ? > Is there a simple workaround ? I hope binding the base version of dlopen to a separate version node works for you. Whether to call that a workaround or a fix to your testcase, I'm not sure. -cary