Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 06 Dec 2022 15:44:22 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: linux-next: build warnings after merge of the powerpc-objtool
 tree
To:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        PowerPC <linuxppc-dev@lists.ozlabs.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        "peterz@infradead.org" <peterz@infradead.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Sathvika Vasireddy <sv@linux.ibm.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
References: <20221125143012.6426c2b9@canb.auug.org.au>
        <6cdad32e-782d-5bb5-f7e9-a44fb0b6444d@linux.ibm.com>
        <c0ed0d60-6014-4c5f-e610-b4d3bd9e9e33@csgroup.eu>
        <74552090-c654-5356-773d-47ead2d63ab2@linux.ibm.com>
In-Reply-To: <74552090-c654-5356-773d-47ead2d63ab2@linux.ibm.com>
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1670317359.hj45ajyl9d.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Sathvika Vasireddy wrote:
>=20
> On 29/11/22 20:58, Christophe Leroy wrote:
>>
>> Le 29/11/2022 =C3=A0 16:13, Sathvika Vasireddy a =C3=A9crit=C2=A0:
>>> Hi all,
>>>
>>> On 25/11/22 09:00, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> After merging the powerpc-objtool tree, today's linux-next build (powe=
rpc
>>>> pseries_le_defconfig) produced these warnings:
>>>>
>>>> arch/powerpc/kernel/head_64.o: warning: objtool: end_first_256B():
>>>> can't find starting instruction
>>>> arch/powerpc/kernel/optprobes_head.o: warning: objtool:
>>>> optprobe_template_end(): can't find starting instruction
>>>>
>>>> I have no idea what started this (they may have been there yesterday).
>>> I was able to recreate the above mentioned warnings with
>>> pseries_le_defconfig and powernv_defconfig. The regression report also
>>> mentions a warning
>>> (https://lore.kernel.org/oe-kbuild-all/202211282102.QUr7HHrW-lkp@intel.=
com/) seen with arch/powerpc/kernel/kvm_emul.S assembly file.
>>>
>>>   =C2=A0[1] arch/powerpc/kernel/optprobes_head.o: warning: objtool:
>>> optprobe_template_end(): can't find starting instruction
>>>   =C2=A0[2] arch/powerpc/kernel/kvm_emul.o: warning: objtool:
>>> kvm_template_end(): can't find starting instruction
>>>   =C2=A0[3] arch/powerpc/kernel/head_64.o: warning: objtool: end_first_=
256B():
>>> can't find starting instruction
>>>
>>> The warnings [1] and [2] go away after adding 'nop' instruction. Below
>>> diff fixes it for me:
>> You have to add NOPs just because those labels are at the end of the
>> files. That's a bit odd.
>> I think either we are missing some kind of flagging for the symbols, or
>> objtool has a bug. In both cases, I'm not sure adding an artificial
>> 'nop' is the solution. At least there should be a big hammer warning
>> explaining why.

The problem looks to be that commit dbcdbdfdf137b4 ("objtool: Rework=20
instruction -> symbol mapping"), which was referenced by Sathvika below,=20
changes how STT_NOTYPE symbols are handled. In the files throwing that=20
warning, there are labels either at the very end of the file, or at the=20
end of a section with no subsequent instruction. Before that commit, we=20
didn't used to expect an instruction for STT_NOTYPE symbols.

>=20
> I don't see these warnings with powerpc/topic/objtool branch. However,=20
> they are seen with linux-next master branch.
> Commit dbcdbdfdf137b49144204571f1a5e5dc01b8aaad objtool: Rework=20
> instruction -> symbol mapping in linux-next is resulting in objtool=20
> can't find starting instruction warnings on powerpc.
>=20
> Reverting this particular hunk (pasted below), resolves it and we don't=20
> see the problem anymore.
>=20
> @@ -427,7 +427,10 @@ static int decode_instructions(struct objtool_file=20
> *file)
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 }
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 list_for_each_entry(func, &sec->symbol_list, list) {
> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (func->type=
 !=3D STT_FUNC || func->alias !=3D func)
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (func->type=
 !=3D STT_NOTYPE && func->type !=3D=20
> STT_FUNC)
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continue;
> +
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (func->retu=
rn_thunk || func->alias !=3D func)
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continue;
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!fin=
d_insn(file, sec, func->offset)) {

We are currently bailing out if find_insn() there fails. Should we=20
instead just continue by not setting insn->sym?

@@ -430,11 +430,8 @@ static int decode_instructions(struct objtool_file *fi=
le)
                        if (func->return_thunk || func->alias !=3D func)
                                continue;
=20
-                       if (!find_insn(file, sec, func->offset)) {
-                               WARN("%s(): can't find starting instruction=
",
-                                    func->name);
-                               return -1;
-                       }
+                       if (!find_insn(file, sec, func->offset))
+                               continue;
=20
                        sym_for_each_insn(file, func, insn) {
                                insn->sym =3D func;


- Naveen