linux-kernel - Re: [RFC PATCH 4/4] objtool/powerpc: Add --mcount specific implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1e2cf35-2a8d-87e6-3a7e-7f144392db23@csgroup.eu>
Date:   Tue, 31 May 2022 08:20:41 +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>,
        Chen Zhongjin <chenzhongjin@...wei.com>
Subject: Re: [RFC PATCH 4/4] objtool/powerpc: Add --mcount specific
 implementation



Le 25/05/2022 à 19:27, Christophe Leroy a écrit :
> 
> 
> 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)
> 

Well, looking once more, and taking into account the patch from Chen 
https://lore.kernel.org/lkml/20220531020744.236970-4-chenzhongjin@huawei.com/

It would be easier to just define two macros:

#define R_ABS64 R_PPC64_ADDR64
#define R_ABS32 R_PPC_ADDR32

And then in the caller, as we know the size, do something like

	size == sizeof(u64) ? R_ABS64 : R_ABS32;

Christophe