Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Florian Weimer <fweimer@redhat.com>
To:     Jiri Slaby <jirislaby@kernel.org>
Cc:     Michal =?utf-8?Q?Such=C3=A1nek?= <msuchanek@suse.de>,
        Jiri Olsa <jolsa@redhat.com>, Yonghong Song <yhs@fb.com>,
        linux-kernel@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>,
        "David S. Miller" <davem@davemloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        David Ahern <dsahern@kernel.org>,
        Jakub Kicinski <kuba@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Song Liu <songliubraving@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>, netdev@vger.kernel.org,
        bpf@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
        Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: linux-next failing build due to missing cubictcp_state symbol
References: <316e86f9-35cc-36b0-1594-00a09631c736@fb.com>
        <20210423175528.GF6564@kitsune.suse.cz>
        <20210425111545.GL15381@kitsune.suse.cz>
        <20210426113215.GM15381@kitsune.suse.cz>
        <20210426121220.GN15381@kitsune.suse.cz>
        <20210426121401.GO15381@kitsune.suse.cz>
        <49f84147-bf32-dc59-48e0-f89241cf6264@fb.com> <YIbkR6z6mxdNSzGO@krava>
        <YIcRlHQWWKbOlcXr@krava> <20210427121237.GK6564@kitsune.suse.cz>
        <20210430174723.GP15381@kitsune.suse.cz>
        <3d148516-0472-8f0a-085b-94d68c5cc0d5@suse.com>
        <6c14f3c8-7474-9f3f-b4a6-2966cb19e1ed@kernel.org>
Date:   Fri, 07 May 2021 09:10:05 +0200
In-Reply-To: <6c14f3c8-7474-9f3f-b4a6-2966cb19e1ed@kernel.org> (Jiri Slaby's
        message of "Mon, 3 May 2021 08:11:50 +0200")
Message-ID: <87lf8rf29e.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Jiri Slaby:

> The dot makes the difference, of course. The question is why is it
> there? I keep looking into it. Only if someone has an immediate
> idea...

We see the failure on aarch64 as well, with 8404c9fbc84b741
(from Linus' tree).

As far as I can tell, the core issue is that BTF_ID is applied to a
symbol which is defined as static on the C side (and even in a different
translation unit, but this aspect doesn't really matter).  The compiler
can and will change symbol names, calling conventions and data layout
for static functions/variables, so this is never going to work reliably.
It is possible to inhibit these optimizations by using __attribute__
((used)).  But I'm pretty sure that BTF generation fails to work
properly if there are symbol name collisions, so I think it's better to
drop the static and rely on duplicate symbol checks from the linker
(which of course does not happen for C entities declared static).

Thanks,
Florian