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:   Thu, 16 Jun 2022 19:04:20 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 4/4] objtool/powerpc: Add --mcount specific
 implementation
To:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        Sathvika Vasireddy <sv@linux.vnet.ibm.com>
Cc:     "aik@ozlabs.ru" <aik@ozlabs.ru>,
        Chen Zhongjin <chenzhongjin@huawei.com>,
        "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "mbenes@suse.cz" <mbenes@suse.cz>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        Sathvika Vasireddy <sv@linux.ibm.com>
References: <20220523175548.922671-1-sv@linux.ibm.com>
        <20220523175548.922671-5-sv@linux.ibm.com>
        <6be5c941-07b0-64d5-7f36-fe5770fb5244@csgroup.eu>
        <59170f18-1356-1140-70e3-30cb627f00bc@linux.vnet.ibm.com>
        <578ec055-0d63-e579-0caa-ad57846b8995@csgroup.eu>
        <f1decbb7-b441-a241-469a-4ba118e08212@csgroup.eu>
        <c1e2cf35-2a8d-87e6-3a7e-7f144392db23@csgroup.eu>
In-Reply-To: <c1e2cf35-2a8d-87e6-3a7e-7f144392db23@csgroup.eu>
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1655386289.uh0k7sgl1r.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Christophe Leroy wrote:
>=20
>=20
> Le 25/05/2022 =C3=A0 19:27, Christophe Leroy a =C3=A9crit=C2=A0:
>>=20
>>=20
>> Le 24/05/2022 =C3=A0 15:33, Christophe Leroy a =C3=A9crit=C2=A0:
>>>
>>>
>>> Le 24/05/2022 =C3=A0 13:00, Sathvika Vasireddy a =C3=A9crit=C2=A0:
>>>>>
>>>>>> +{
>>>>>> +=C2=A0=C2=A0=C2=A0 switch (elf->ehdr.e_machine) {
>>>>>> +=C2=A0=C2=A0=C2=A0 case EM_X86_64:
>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
return R_X86_64_64;
>>>>>> +=C2=A0=C2=A0=C2=A0 case EM_PPC64:
>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
return R_PPC64_ADDR64;
>>>>>> +=C2=A0=C2=A0=C2=A0 default:
>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
WARN("unknown machine...");
>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
exit(-1);
>>>>>> +=C2=A0=C2=A0=C2=A0 }
>>>>>> +}
>>>>> Wouldn't it be better to make that function arch specific ?
>>>>
>>>> This is so that we can support cross architecture builds.
>>>>
>>>
>>>
>>> I'm not sure I follow you here.
>>>
>>> This is only based on the target, it doesn't depend on the build host so
>>> I can't the link with cross arch builds.
>>>
>>> The same as you have arch_decode_instruction(), you could have
>>> arch_elf_reloc_type_long()
>>> It would make sense indeed, because there is no point in supporting X86
>>> relocation when you don't support X86 instruction decoding.
>>>
>>=20
>> Could simply be some macro defined in=20
>> tools/objtool/arch/powerpc/include/arch/elf.h and=20
>> tools/objtool/arch/x86/include/arch/elf.h
>>=20
>> The x86 version would be:
>>=20
>> #define R_ADDR(elf) R_X86_64_64
>>=20
>> And the powerpc version would be:
>>=20
>> #define R_ADDR(elf) (elf->ehdr.e_machine =3D=3D EM_PPC64 ? R_PPC64_ADDR6=
4 :=20
>> R_PPC_ADDR32)
>>=20
>=20
> Well, looking once more, and taking into account the patch from Chen=20
> https://lore.kernel.org/lkml/20220531020744.236970-4-chenzhongjin@huawei.=
com/
>=20
> It would be easier to just define two macros:
>=20
> #define R_ABS64 R_PPC64_ADDR64
> #define R_ABS32 R_PPC_ADDR32
>=20
> And then in the caller, as we know the size, do something like
>=20
> 	size =3D=3D sizeof(u64) ? R_ABS64 : R_ABS32;

How does 'sizeof(u64)' work here?


- Naveen