From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2326C433EF for ; Sat, 16 Apr 2022 16:28:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232523AbiDPQaz (ORCPT ); Sat, 16 Apr 2022 12:30:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230108AbiDPQay (ORCPT ); Sat, 16 Apr 2022 12:30:54 -0400 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69CBA2DCC for ; Sat, 16 Apr 2022 09:28:22 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id s137so11415606pgs.5 for ; Sat, 16 Apr 2022 09:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HwNIbLRR7Kdkc+05Ru8kr6NP0tZCZs+cT5h6xauTCDg=; b=ljGL+p800Fc1MHR1s7PkxaQZLDaqA41rgFwYSzkGbKV99LBH5u8gW9tlnvwMkwdjR7 OlWrDY2LL8TfQjN2+MyD+8i+tyIHup27G/9wZDhy6HN95jI9ibtzG+aEtYzTHezt+a3H wlCjmAnDPx8kVCNNfqMKD4jfARfr0wwq6VHlROKba2Q+IuwD6g6fvXewhkzulbOiYkuf gC6/u+sn6De3qWX/EmhgdAxaTrh+2PpgHkYYjuxe1ZFOBgHvp8FNfNL3gFnKHhVzmU4P mPda4qYbb1/uJs/virT1/6SaSHtoh4w2O4pU9j1q/AnsHcU0xvMbX7OJEasJVF0DAFQm 8Iaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HwNIbLRR7Kdkc+05Ru8kr6NP0tZCZs+cT5h6xauTCDg=; b=I1zjkUwGC5WSVu+w7Gx+5P5Lh2qcvXTiJYIMfBy9r/tGm9w3vTtlBhqv+9LBN8Bjfl edxn4EsUuZFc/qb1vY0tIxHZUwxC90FV6lt5PWMLEAZJqo6/odCvEcbRnlbUfXrqxvjm g7FRHWPIiuRHHs3BVlxzvVoZ7XD8KFdAHQwgLwPpTsdpdgiVBRRONOgKwYbAHHEPLBsM vmotaWQ2D2yTk2YrGfrKaw+4zF6R3TcbUFUURWZTPuetNTWI0nlGMb1r9cAVxkmfXGQl 2BvOTty9ijv8a7gVJun29CvQ1E0tzt7L0RWSP1Pk0bz8fI3QfCh12ugEeD0r8Ju5xUuT bZsw== X-Gm-Message-State: AOAM530vRzs8FjP5iUhVwEbHAAGANK2Ymir32D+P947bnoB/NLGBfoFY Z5ZZ/jBVhSyegT62GGMlx5Xj+o5JrLQJnFpbEOI= X-Google-Smtp-Source: ABdhPJyGoqBHisFyDYaUD2GoL2GgCXIDMYnhKt7DbmSsLMjkHSZ27RxPt1UU4J3qhaStwStXPdOiA6BQH491VkUf8w0= X-Received: by 2002:aa7:8d54:0:b0:4e0:bd6:cfb9 with SMTP id s20-20020aa78d54000000b004e00bd6cfb9mr4285661pfe.60.1650126501771; Sat, 16 Apr 2022 09:28:21 -0700 (PDT) MIME-Version: 1.0 References: <20220416112546.GG2731@worktop.programming.kicks-ass.net> In-Reply-To: <20220416112546.GG2731@worktop.programming.kicks-ass.net> From: "H.J. Lu" Date: Sat, 16 Apr 2022 09:27:45 -0700 Message-ID: Subject: Re: The trouble with __weak and objtool got worse To: Peter Zijlstra Cc: "the arch/x86 maintainers" , Josh Poimboeuf , Nick Desaulniers , Miroslav Benes , rostedt@goodmis.org, linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Sat, Apr 16, 2022 at 4:25 AM Peter Zijlstra wrote: > > On Fri, Apr 15, 2022 at 02:04:32PM -0700, H.J. Lu wrote: > > On Fri, Apr 15, 2022 at 4:19 AM Peter Zijlstra wrote: > > > > *HOWEVER*, sometimes it generates things like this (using new enough > > > binutils): > > > > > > foo-weak.o: > > > > > > Relocation section '.rela.static_call_sites' at offset 0x2c8 contains 1 entry: > > > Offset Info Type Symbol's Value Symbol's Name + Addend > > > 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 foo + 0 > > > 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 > > > > > > foo.o: > > > > > > Relocation section '.rela.static_call_sites' at offset 0x310 contains 2 entries: > > > Offset Info Type Symbol's Value Symbol's Name + Addend > > > 0000000000000000 0000000200000002 R_X86_64_PC32 0000000000000000 foo + d > > > 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 > > > > > > foos.o: > > > > > > Relocation section '.rela.static_call_sites' at offset 0x430 contains 4 entries: > > > Offset Info Type Symbol's Value Symbol's Name + Addend > > > 0000000000000000 0000000100000002 R_X86_64_PC32 0000000000000000 foo + 0 > > > 0000000000000004 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 > > > 0000000000000008 0000000100000002 R_X86_64_PC32 0000000000000000 foo + d > > > 000000000000000c 0000000d00000002 R_X86_64_PC32 0000000000000000 __SCT__foo + 1 > > > > > > And now we can see how that foos.o .static_call_sites goes side-ways, we > > > now have _two_ patch sites in foo. One for the weak symbol at foo+0 > > > (which is no longer a static_call site!) and one at foo+d which is in > > > fact the right location. > > > > This can't be right. "foo" must point to the non-weak function. > > Please file a linker bug report. > > It does point to the non-weak symbol; they both do, even the relocs that > started out as pointing to the weak symbol. The relocation is against the symbol, foo, and linker will decide where foo is defined. We only know what the final foo definition is at link-time. You can't tell the final foo definition is weak or non-weak before link-time. > Are you saying the linker *should* have removed the relocs that were > based on the weak symbol? No, relocations aren't removed. Linker ignores the weak definition of foo if there is a non-weak definition of foo when resolving relocations against symbol foo. -- H.J.