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:   Fri, 17 Jun 2022 19:34:48 +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>,
        Peter Zijlstra <peterz@infradead.org>
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>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        Sathvika Vasireddy <sv@linux.ibm.com>,
        Sathvika Vasireddy <sv@linux.vnet.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>
        <1655386289.uh0k7sgl1r.naveen@linux.ibm.com>
        <30f3791c-0fdd-e635-4a85-ec457f990fae@csgroup.eu>
        <Yqs235037JrOOhBA@hirez.programming.kicks-ass.net>
        <d095fe9d-e713-def1-6096-540c0d0da298@csgroup.eu>
In-Reply-To: <d095fe9d-e713-def1-6096-540c0d0da298@csgroup.eu>
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1655474054.lvnbqfz64f.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 16/06/2022 =C3=A0 15:57, Peter Zijlstra a =C3=A9crit=C2=A0:
>> On Thu, Jun 16, 2022 at 01:40:34PM +0000, Christophe Leroy wrote:
>>> sizeof(u64) is always 8 by definition.
>>>
>>> So if size is 8 we are working on a binary file for a 64 bits target, if
>>> not it means we are working for a 32 bits target.
>>=20
>> Cross-builds invalidate this I think. Best to look at something like:
>>=20
>>    elf->ehdr.e_ident[EI_CLASS] =3D=3D ELFCLASS32
>>=20
>>=20
>=20
> Yes that's what it does indirectly:
>=20
> 	int size =3D elf_class_size(elf);
>=20
>=20
> With
>=20
> static inline int elf_class_size(struct elf *elf)
> {
> 	if (elf->ehdr.e_ident[EI_CLASS] =3D=3D ELFCLASS32)
> 		return sizeof(u32);
> 	else
> 		return sizeof(u64);
> }

Ok, those come from the below patch:
https://lore.kernel.org/all/c4b06b5b314183d85615765a5ce421a057674bd8.165339=
8233.git.christophe.leroy@csgroup.eu/T/#u

I guess it would have been clearer if 'size' was named differently:=20
'addr_size' perhaps?


- Naveen