From: Chen Zhongjin <chenzhongjin@huawei.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "jpoimboe@kernel.org" <jpoimboe@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@suse.de" <bp@suse.de>,
"mhiramat@kernel.org" <mhiramat@kernel.org>,
"sv@linux.ibm.com" <sv@linux.ibm.com>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: [PATCH] objtool: replace _ASM_PTR with quad in macros
Date: Wed, 24 Aug 2022 10:06:53 +0800 [thread overview]
Message-ID: <3d479f53-9028-1640-985f-0fdd084c5037@huawei.com> (raw)
In-Reply-To: <27c6906c-baf3-6802-9843-50b27df74a71@csgroup.eu>
On 2022/8/24 0:47, Christophe Leroy wrote:
>
> Le 23/08/2022 à 15:31, Chen Zhongjin a écrit :
>> Macros STACK_FRAME_NON_STANDARD and ANNOTATE_NOENDBR uses
>> _ASM_PTR. It switch between .long and .quad based on 32bit
>> or 64bit. However objtool doesn't work for 32bit, so _ASM_PTR
>> makes no sense.
>>
>> Considering that _ASM_PTR comes from asm.h, which is x86
>> specific head file, while objtool.h is generic. Replace
>> _ASM_PTR with quad and remove asm.h reference.
> objtool is about to be used on powerpc on both PPC32 and PPC64, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=312955&state=*
>
> So if this part is meant to be used by all architectures, we need
> nothing that also works on 32 bits, don't we ?
>
> Christophe
>
ANNOTATE_NOENDBR affects nothing because it's for x86 IBT. Leaving this
macro here is harmless now, but I think maybe it's better to move this
to arch-specific.
The problem is STACK_FRAME_NON_STANDARD. The C version macro uses
function pointer so the reloc symbol type can change between 32 and 64 bit.
Although I think quad is workable for both 32 and 64 bit, and this macro
is .discard so it won't affect something else, but it may not keep reloc
symbol type consistency.
Anyway, NO _ASM_PTR and asm.h, they are arch-specific and will break
compiling on other arches.
Maybe we should create a macro similar to _ASM_PTR for other arches.
Till now I didn't find one.
I'll send v2 patch to make this and Peter can judge.
Best,
Chen
>> Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
>> ---
>> include/linux/objtool.h | 6 ++----
>> tools/include/linux/objtool.h | 6 ++----
>> 2 files changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/objtool.h b/include/linux/objtool.h
>> index 62c54ffbeeaa..d2413cb78037 100644
>> --- a/include/linux/objtool.h
>> +++ b/include/linux/objtool.h
>> @@ -45,8 +45,6 @@ struct unwind_hint {
>>
>> #ifdef CONFIG_OBJTOOL
>>
>> -#include <asm/asm.h>
>> -
>> #ifndef __ASSEMBLY__
>>
>> #define UNWIND_HINT(sp_reg, sp_offset, type, end) \
>> @@ -87,7 +85,7 @@ struct unwind_hint {
>> #define ANNOTATE_NOENDBR \
>> "986: \n\t" \
>> ".pushsection .discard.noendbr\n\t" \
>> - _ASM_PTR " 986b\n\t" \
>> + ".quad 986b\n\t" \
>> ".popsection\n\t"
>>
>> #define ASM_REACHABLE \
>> @@ -144,7 +142,7 @@ struct unwind_hint {
>>
>> .macro STACK_FRAME_NON_STANDARD func:req
>> .pushsection .discard.func_stack_frame_non_standard, "aw"
>> - _ASM_PTR \func
>> + .quad \func
>> .popsection
>> .endm
>>
>> diff --git a/tools/include/linux/objtool.h b/tools/include/linux/objtool.h
>> index 62c54ffbeeaa..d2413cb78037 100644
>> --- a/tools/include/linux/objtool.h
>> +++ b/tools/include/linux/objtool.h
>> @@ -45,8 +45,6 @@ struct unwind_hint {
>>
>> #ifdef CONFIG_OBJTOOL
>>
>> -#include <asm/asm.h>
>> -
>> #ifndef __ASSEMBLY__
>>
>> #define UNWIND_HINT(sp_reg, sp_offset, type, end) \
>> @@ -87,7 +85,7 @@ struct unwind_hint {
>> #define ANNOTATE_NOENDBR \
>> "986: \n\t" \
>> ".pushsection .discard.noendbr\n\t" \
>> - _ASM_PTR " 986b\n\t" \
>> + ".quad 986b\n\t" \
>> ".popsection\n\t"
>>
>> #define ASM_REACHABLE \
>> @@ -144,7 +142,7 @@ struct unwind_hint {
>>
>> .macro STACK_FRAME_NON_STANDARD func:req
>> .pushsection .discard.func_stack_frame_non_standard, "aw"
>> - _ASM_PTR \func
>> + .quad \func
>> .popsection
>> .endm
>>
next prev parent reply other threads:[~2022-08-24 2:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 13:31 Chen Zhongjin
2022-08-23 16:47 ` Christophe Leroy
2022-08-24 2:06 ` Chen Zhongjin [this message]
2022-08-24 2:48 ` Chen Zhongjin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d479f53-9028-1640-985f-0fdd084c5037@huawei.com \
--to=chenzhongjin@huawei.com \
--cc=bp@suse.de \
--cc=christophe.leroy@csgroup.eu \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@kernel.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=sv@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®