From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 215193839D1F for ; Sat, 10 Dec 2022 03:45:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 215193839D1F 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-pf1-x434.google.com with SMTP id 124so5052275pfy.0 for ; Fri, 09 Dec 2022 19:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Bu37m27W6zxsD0w1o5eHr6A6YiGto7BvvC75qrgW6eM=; b=EdN7UGhxW6PsbJ6bi+VamBPRKaRa1tIH8M+epRrtD7I5F6oeQ8RaChjxEnnJRHUS25 XnnWBFTbDpJeF4N1JxWZDbONAOK/nNlfYtJjw6HMblQASN65l9o9w1fAR0E9bo07RYvp EnHD1WTUEvCfWjfuOb+ydki4j7RIHO8uH2ipDPERdVutsYhBW6SO3r2Ss5i7H1Vk1Y// etAX1sjhbVg2fobER/myEzElHzChofRnkxa+xxRKrf9NaL8AhT1tDy2edyEw42S3W3p0 14xGASZUFX6mI4ZqzbK0zUNxdB/l3qs7VoWaR6j2kSWfC1YCPrUZPoISEzTcrLAp+1MZ GbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=Bu37m27W6zxsD0w1o5eHr6A6YiGto7BvvC75qrgW6eM=; b=5AbeaHQBjGVxUcleo19rzidTF7u74us0wdT3JKS3XI9IsxJzPkRomDjf2drJVL2h6R KFp624Y6mKJNYKLo7STQ05sbXcQkenu1sNEgOpLs241TEChDrAejgRat3WkfjaxDIENK iVT/44ZZHOruEsOUez9/FxK0r5zNyG1OrBc4LDusqCDRyOp6kg0TLjv6Re02e/3DUtLg HAtLKEvVvZAJQ1N/2QeTTb5A5uzpZ8cx17c9nOL6680HVwRUcUtTQCv8fr0gqfLN4M0Z 7etVpHzbad1llayzoX99uJlo4hosEWjtNKbTO/H3cUTik1OsvVFrBa8rIvD5YW4Nm4YT FhjQ== X-Gm-Message-State: ANoB5pnfue3SzGTE1lLaoWsAw3IhwaZIqMnN2szg8MgHwhoR1zoDltYU D+yu9T/Z+Ik/Jkawxv7lG5GnjgRR3XXY4k4PWlg= X-Google-Smtp-Source: AA0mqf44bOWy/cQlFggu4/68efw3en/ft8E6zvtqoTbk2t8ldQTK9UsGZHrSXjYOhPUZ7AZKEOCK0ddHbXP5EExJDOI= X-Received: by 2002:a63:ce42:0:b0:478:d4ce:5d3f with SMTP id r2-20020a63ce42000000b00478d4ce5d3fmr12718032pgi.277.1670643942932; Fri, 09 Dec 2022 19:45:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Fri, 9 Dec 2022 19:45:30 -0800 Message-ID: Subject: Re: A problem of weak & weakref function attribute To: =?UTF-8?B?5YiY55WF?= Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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: On Fri, Dec 9, 2022 at 7:17 PM =E5=88=98=E7=95=85 via Gcc = wrote: > > Hi all, > > I met a problem when I was testing the weak attribute and the weakref > attribute of GCC. I've read the documentation and in the 6.33.1 Common > Function Attributes - weakref part I found: > > Without a target given as an argument to weakref or to alias, > weakref is equivalent to weak (in that case the declaration may be > extern). > > To verify this statement, I wrote the following two C programs: > > a.c > #include > > void func(void) __attribute__((weak)); > > int main() { > if (func) > printf("1\n"); > else > printf("0\n"); > > return 0; > } > > b.c > #include > > extern void func(void) __attribute__((weakref)); > > int main() { > if (func) > printf("1\n"); > else > printf("0\n"); > > return 0; > } > > The only difference is a.c uses __attribute__((weak)) while b.c uses > __attribute__((weakref)). According to the statement I referred above, > I expect the two programs have the smae behavior. However, after I > compiled the two programs with: > > $ gcc a.c -o a.out; gcc b.c -o b.out > > I got a warning: > > b.c:3:13: warning: =E2=80=98weakref=E2=80=99 attribute should be accompan= ied with an > =E2=80=98alias=E2=80=99 attribute [-Wattributes] > 3 | extern void func(void) __attribute__((weakref)); > | > > then I found they have different output: > > $ ./a.out; ./b.out > 0 > 1 > > Then I disassembled the main function of a.out and b.out, and found > the func symbol didn't even appear in the assemble code of b.c (I > recompiled the 2 programs with -g option): > > assemble code of a.c: > 5 int main() { > 0x0000000000001149 <+0>: f3 0f 1e fa endbr64 > 0x000000000000114d <+4>: 55 push %rbp > 0x000000000000114e <+5>: 48 89 e5 mov %rsp,%rbp > > 6 if (func) > 0x0000000000001151 <+8>: 48 8b 05 90 2e 00 00 mov > 0x2e90(%rip),%rax # 0x3fe8 > 0x0000000000001158 <+15>: 48 85 c0 test %rax,%rax > 0x000000000000115b <+18>: 74 0e je 0x116b > > 7 printf("1\n"); > 0x000000000000115d <+20>: 48 8d 3d a0 0e 00 00 lea > 0xea0(%rip),%rdi # 0x2004 > 0x0000000000001164 <+27>: e8 e7 fe ff ff callq 0x1050 > 0x0000000000001169 <+32>: eb 0c jmp 0x1177 > > 8 else > 9 printf("0\n"); > 0x000000000000116b <+34>: 48 8d 3d 94 0e 00 00 lea > 0xe94(%rip),%rdi # 0x2006 > 0x0000000000001172 <+41>: e8 d9 fe ff ff callq 0x1050 > > 10 > 11 return 0; > 0x0000000000001177 <+46>: b8 00 00 00 00 mov $0x0,%eax > > 12 } > 0x000000000000117c <+51>: 5d pop %rbp > 0x000000000000117d <+52>: c3 retq > > assemble code of b.c: > 5 int main() { > 0x0000000000001149 <+0>: f3 0f 1e fa endbr64 > 0x000000000000114d <+4>: 55 push %rbp > 0x000000000000114e <+5>: 48 89 e5 mov %rsp,%rbp > > 6 if (func) > 7 printf("1\n"); > 0x0000000000001151 <+8>: 48 8d 3d ac 0e 00 00 lea > 0xeac(%rip),%rdi # 0x2004 > 0x0000000000001158 <+15>: e8 f3 fe ff ff callq 0x1050 > > 8 else > 9 printf("0\n"); > 10 > 11 return 0; > 0x000000000000115d <+20>: b8 00 00 00 00 mov $0x0,%eax > > 12 } > 0x0000000000001162 <+25>: 5d pop %rbp > 0x0000000000001163 <+26>: c3 retq > > In my test, the weak attribute and the weakref attribute without a > target given as an argument to weakref or to alias have different > behavior, which is different from the documentation. I don't know if > it's because I misunderstood the documentation. I would be appreciate > if anyone can help me :) No it is a bug, at least the documentation no longer matches the implementa= tion. I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108042 and even pointed out the (old) revision which changed the behavior to no longer match the documentation. Thanks, Andrew > > Best regards, > > Chang Liu