[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1decbb7-b441-a241-469a-4ba118e08212@csgroup.eu>
Date: Wed, 25 May 2022 19:27:31 +0200
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Sathvika Vasireddy <sv@...ux.vnet.ibm.com>
Cc: "peterz@...radead.org" <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"aik@...abs.ru" <aik@...abs.ru>,
Sathvika Vasireddy <sv@...ux.ibm.com>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"naveen.n.rao@...ux.vnet.ibm.com" <naveen.n.rao@...ux.vnet.ibm.com>,
"mbenes@...e.cz" <mbenes@...e.cz>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [RFC PATCH 4/4] objtool/powerpc: Add --mcount specific
implementation
Le 24/05/2022 à 15:33, Christophe Leroy a écrit :
>
>
> Le 24/05/2022 à 13:00, Sathvika Vasireddy a écrit :
>>>
>>>> +{
>>>> + switch (elf->ehdr.e_machine) {
>>>> + case EM_X86_64:
>>>> + return R_X86_64_64;
>>>> + case EM_PPC64:
>>>> + return R_PPC64_ADDR64;
>>>> + default:
>>>> + WARN("unknown machine...");
>>>> + exit(-1);
>>>> + }
>>>> +}
>>> 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.
>
Could simply be some macro defined in
tools/objtool/arch/powerpc/include/arch/elf.h and
tools/objtool/arch/x86/include/arch/elf.h
The x86 version would be:
#define R_ADDR(elf) R_X86_64_64
And the powerpc version would be:
#define R_ADDR(elf) (elf->ehdr.e_machine == EM_PPC64 ? R_PPC64_ADDR64 :
R_PPC_ADDR32)
Christophe
Powered by blists - more mailing lists