From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Peter Zijlstra <peterz@infradead.org>,
Sathvika Vasireddy <sv@linux.ibm.com>
Cc: "aik@ozlabs.ru" <aik@ozlabs.ru>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Josh Poimboeuf <jpoimboe@kernel.org>
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions
Date: Mon, 23 May 2022 11:09:19 +0530 [thread overview]
Message-ID: <1653283961.ozxe2866nt.naveen@linux.ibm.com> (raw)
In-Reply-To: <20220521105704.GE2578@worktop.programming.kicks-ass.net>
Peter Zijlstra wrote:
> On Sat, May 21, 2022 at 09:38:35AM +0000, Christophe Leroy wrote:
>
>> I gave it a try this morning, I selected HAVE_OBJTOOL and
>> HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
>>
>>
>> Seems like there are still some x86 arch specific stuff in common common
>> code and I get the following errors.
>
> I'm assuming there's a metric ton of x86 specific stuff in there.
> That'll take a while to clean out.
>
> Mostly Josh's rewrite was centered around splitting out the runtime
> options, but objtool is still always build with all options included,
> even the ones you're not using for your arch, which is what's triggering
> the problems you see here, I suppose...
>
>> Also, is it normal to get those functions built allthough I have not
>> selected HAVE_STACK_VALIDATION ?
>>
>> CC /home/chleroy/linux-powerpc/tools/objtool/check.o
>> check.c: In function 'has_valid_stack_frame':
>> check.c:2369:30: error: 'CFI_BP' undeclared (first use in this
>> function); did you mean 'CFI_SP'?
>> 2369 | if (cfi->cfa.base == CFI_BP &&
>> | ^~~~~~
>> | CFI_SP
>> check.c:2369:30: note: each undeclared identifier is reported only once
>> for each function it appears in
>> check.c:2371:44: error: 'CFI_RA' undeclared (first use in this
>> function); did you mean 'CFI_R3'?
>> 2371 | check_reg_frame_pos(&cfi->regs[CFI_RA],
>> -cfi->cfa.offset + 8))
>> | ^~~~~~
>> | CFI_R3
>> check.c: In function 'update_cfi_state':
>> check.c:2499:70: error: 'CFI_BP' undeclared (first use in this
>> function); did you mean 'CFI_SP'?
>> 2499 | if (op->src.reg == CFI_SP &&
>> op->dest.reg == CFI_BP &&
>> |
>> ^~~~~~
>> |
>> CFI_SP
>> make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97:
>> /home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
>> make[2]: *** [Makefile:54:
>> /home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
>> make[1]: *** [Makefile:69: objtool] Error 2
>> make: *** [Makefile:1337: tools/objtool] Error 2
>>
>>
>> What would be the best approach to fix that ?
>
> Define CFI_BP to your frame register (r2, afaict) I suppose. If you're
> only using OBJTOOL_MCOUNT this code will never run, so all you have to
> ensure is that it compiles, not that it makes sense (-:
Sathvika has been looking into this.
>
> The very long and complicated way would be to propagate the various
> CONFIG_HAVE_* build time things to the objtool build and librally
> sprinkle a lot of #ifdef around.
I think there were just a couple of unrelated checks/warnings that were
causing problems on powerpc. So, we likely won't need too many #ifdefs,
at least for mcount purposes.
Sathvika,
Can you post what you have?
- Naveen
WARNING: multiple messages have this Message-ID (diff)
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
Peter Zijlstra <peterz@infradead.org>,
Sathvika Vasireddy <sv@linux.ibm.com>
Cc: "aik@ozlabs.ru" <aik@ozlabs.ru>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions
Date: Mon, 23 May 2022 11:09:19 +0530 [thread overview]
Message-ID: <1653283961.ozxe2866nt.naveen@linux.ibm.com> (raw)
In-Reply-To: <20220521105704.GE2578@worktop.programming.kicks-ass.net>
Peter Zijlstra wrote:
> On Sat, May 21, 2022 at 09:38:35AM +0000, Christophe Leroy wrote:
>
>> I gave it a try this morning, I selected HAVE_OBJTOOL and
>> HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
>>
>>
>> Seems like there are still some x86 arch specific stuff in common common
>> code and I get the following errors.
>
> I'm assuming there's a metric ton of x86 specific stuff in there.
> That'll take a while to clean out.
>
> Mostly Josh's rewrite was centered around splitting out the runtime
> options, but objtool is still always build with all options included,
> even the ones you're not using for your arch, which is what's triggering
> the problems you see here, I suppose...
>
>> Also, is it normal to get those functions built allthough I have not
>> selected HAVE_STACK_VALIDATION ?
>>
>> CC /home/chleroy/linux-powerpc/tools/objtool/check.o
>> check.c: In function 'has_valid_stack_frame':
>> check.c:2369:30: error: 'CFI_BP' undeclared (first use in this
>> function); did you mean 'CFI_SP'?
>> 2369 | if (cfi->cfa.base == CFI_BP &&
>> | ^~~~~~
>> | CFI_SP
>> check.c:2369:30: note: each undeclared identifier is reported only once
>> for each function it appears in
>> check.c:2371:44: error: 'CFI_RA' undeclared (first use in this
>> function); did you mean 'CFI_R3'?
>> 2371 | check_reg_frame_pos(&cfi->regs[CFI_RA],
>> -cfi->cfa.offset + 8))
>> | ^~~~~~
>> | CFI_R3
>> check.c: In function 'update_cfi_state':
>> check.c:2499:70: error: 'CFI_BP' undeclared (first use in this
>> function); did you mean 'CFI_SP'?
>> 2499 | if (op->src.reg == CFI_SP &&
>> op->dest.reg == CFI_BP &&
>> |
>> ^~~~~~
>> |
>> CFI_SP
>> make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97:
>> /home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
>> make[2]: *** [Makefile:54:
>> /home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
>> make[1]: *** [Makefile:69: objtool] Error 2
>> make: *** [Makefile:1337: tools/objtool] Error 2
>>
>>
>> What would be the best approach to fix that ?
>
> Define CFI_BP to your frame register (r2, afaict) I suppose. If you're
> only using OBJTOOL_MCOUNT this code will never run, so all you have to
> ensure is that it compiles, not that it makes sense (-:
Sathvika has been looking into this.
>
> The very long and complicated way would be to propagate the various
> CONFIG_HAVE_* build time things to the objtool build and librally
> sprinkle a lot of #ifdef around.
I think there were just a couple of unrelated checks/warnings that were
causing problems on powerpc. So, we likely won't need too many #ifdefs,
at least for mcount purposes.
Sathvika,
Can you post what you have?
- Naveen
next prev parent reply other threads:[~2022-05-23 5:41 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 10:51 [RFC PATCH 0/3] objtool: Add mcount sub-command Sathvika Vasireddy
2022-03-18 10:51 ` Sathvika Vasireddy
2022-03-18 10:51 ` [RFC PATCH 1/3] objtool: Move common code to utils.c Sathvika Vasireddy
2022-03-18 10:51 ` Sathvika Vasireddy
2022-03-23 18:02 ` Miroslav Benes
2022-03-23 18:02 ` Miroslav Benes
2022-03-18 10:51 ` [RFC PATCH 2/3] objtool: Enable and implement 'mcount' subcommand Sathvika Vasireddy
2022-03-18 10:51 ` Sathvika Vasireddy
2022-03-21 7:06 ` Christophe Leroy
2022-03-21 8:19 ` Naveen N. Rao
2022-03-21 8:19 ` Naveen N. Rao
2022-03-21 8:26 ` Christophe Leroy
2022-03-21 8:26 ` Christophe Leroy
2022-03-21 9:48 ` Naveen N. Rao
2022-03-21 9:48 ` Naveen N. Rao
2022-03-18 10:51 ` [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions Sathvika Vasireddy
2022-03-18 10:51 ` Sathvika Vasireddy
2022-03-18 12:26 ` Peter Zijlstra
2022-03-18 12:26 ` Peter Zijlstra
2022-03-18 13:59 ` Christophe Leroy
2022-03-18 13:59 ` Christophe Leroy
2022-03-21 2:27 ` Michael Ellerman
2022-03-21 6:47 ` Christophe Leroy
2022-03-21 7:46 ` Christophe Leroy
2022-03-21 7:56 ` Christophe Leroy
2022-03-21 8:30 ` Christophe Leroy
2022-03-21 8:59 ` Christophe Leroy
2022-03-26 7:58 ` Christophe Leroy
2022-03-26 7:58 ` Christophe Leroy
2022-03-21 6:25 ` Naveen N. Rao
2022-03-21 6:25 ` Naveen N. Rao
2022-03-27 9:09 ` Christophe Leroy
2022-03-27 9:09 ` Christophe Leroy
2022-03-28 19:59 ` Josh Poimboeuf
2022-03-28 19:59 ` Josh Poimboeuf
2022-03-28 20:14 ` Peter Zijlstra
2022-03-28 20:14 ` Peter Zijlstra
2022-03-28 20:15 ` Peter Zijlstra
2022-03-28 20:15 ` Peter Zijlstra
2022-03-28 20:21 ` Josh Poimboeuf
2022-03-28 20:21 ` Josh Poimboeuf
2022-03-29 12:01 ` Michael Ellerman
2022-03-29 12:01 ` Michael Ellerman
2022-03-29 17:32 ` Christophe Leroy
2022-03-30 4:26 ` Josh Poimboeuf
2022-03-30 4:26 ` Josh Poimboeuf
2022-03-30 18:40 ` Naveen N. Rao
2022-03-30 18:40 ` Naveen N. Rao
2022-05-12 14:52 ` Christophe Leroy
2022-05-12 14:52 ` Christophe Leroy
2022-05-12 15:12 ` Josh Poimboeuf
2022-05-12 15:12 ` Josh Poimboeuf
2022-05-21 9:38 ` Christophe Leroy
2022-05-21 9:38 ` Christophe Leroy
2022-05-21 10:57 ` Peter Zijlstra
2022-05-21 10:57 ` Peter Zijlstra
2022-05-23 5:39 ` Naveen N. Rao [this message]
2022-05-23 5:39 ` Naveen N. Rao
2022-03-19 1:35 ` [RFC PATCH 0/3] objtool: Add mcount sub-command Josh Poimboeuf
2022-03-19 1:35 ` Josh Poimboeuf
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=1653283961.ozxe2866nt.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=aik@ozlabs.ru \
--cc=christophe.leroy@csgroup.eu \
--cc=jpoimboe@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.