LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] powerpc/64e: Fix obtool warnings in exceptions-64e.S
Date: Fri, 23 Jun 2023 09:46:32 +1000	[thread overview]
Message-ID: <875y7fnjqf.fsf@mail.lhotse> (raw)
In-Reply-To: <11d08617-8fe6-5d5e-866c-5e30517363f3@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 22/06/2023 à 13:24, Michael Ellerman a écrit :
>> Since commit aec0ba7472a7 ("powerpc/64: Use -mprofile-kernel for big
>> endian ELFv2 kernels"), this file is checked by objtool. Fix warnings
>> such as:
>> 
>>    arch/powerpc/kernel/idle_64e.o: warning: objtool: .text+0x20: unannotated intra-function call
>>    arch/powerpc/kernel/exceptions-64e.o: warning: objtool: .text+0x218: unannotated intra-function call
>> 
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>>   arch/powerpc/kernel/exceptions-64e.S | 31 ++++++++++++++++------------
>>   1 file changed, 18 insertions(+), 13 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
>> index 3f86091e68b3..7ab4c8c0f1ab 100644
>> --- a/arch/powerpc/kernel/exceptions-64e.S
>> +++ b/arch/powerpc/kernel/exceptions-64e.S
>> @@ -1030,8 +1037,7 @@ BAD_STACK_TRAMPOLINE(0xe00)
>>   BAD_STACK_TRAMPOLINE(0xf00)
>>   BAD_STACK_TRAMPOLINE(0xf20)
>>   
>> -	.globl	bad_stack_book3e
>> -bad_stack_book3e:
>> +_GLOBAL(bad_stack_book3e)
>>   	/* XXX: Needs to make SPRN_SPRG_GEN depend on exception type */
>>   	mfspr	r10,SPRN_SRR0;		  /* read SRR0 before touching stack */
>>   	ld	r1,PACAEMERGSP(r13)
>
> If we start playing with that now, allthough I have a patch in my 
> UACCESS validation series that totally disables OBJTOOL for ASM files,

Yeah I saw that, and it's probably a good idea in the interim while
we're getting all the uaccess stuff sorted out.

Though these warnings are firing today in my next branch, so I'll plan
to merge this patch for 6.5 to squash them.

> can we ban _GLOBAL macro and use SYM_FUNC_START / SYM_FUNC_END instead ?

Yeah, I'm not a fan of _GLOBAL, it does too much.

We'd obviously need to override the generic SYMC_FUNC_START to do all
the TOC setup and so on when it's needed.

cheers

  reply	other threads:[~2023-06-22 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 11:24 [PATCH] powerpc/64e: Fix obtool warnings in exceptions-64e.S Michael Ellerman
2023-06-22 12:06 ` Christophe Leroy
2023-06-22 23:46   ` Michael Ellerman [this message]
2023-07-17  0:29 ` Michael Ellerman

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=875y7fnjqf.fsf@mail.lhotse \
    --to=mpe@ellerman.id.au \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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