linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Naveen N Rao <naveen@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sathvika Vasireddy <sv@linux.ibm.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1 2/3] powerpc: Mark all .S files invalid for objtool
Date: Tue, 20 Jun 2023 12:10:23 +0530	[thread overview]
Message-ID: <1687242440.kuukzoknou.naveen@kernel.org> (raw)
In-Reply-To: <185a1734-80a3-08fd-18d2-08b24acace37@csgroup.eu>

Christophe Leroy wrote:
> 
> 
> Le 20/06/2023 à 08:04, Naveen N Rao a écrit :
>> Christophe Leroy wrote:
>>> A lot of work is required in .S files in order to get them ready
>>> for objtool checks.
>>>
>>> For the time being, exclude them from the checks.
>>>
>>> This is done with the script below:
>>>
>>>     #!/bin/sh
>>>     DIRS=`find arch/powerpc -name "*.S" -exec dirname {} \; | sort | 
>>> uniq`
>>>     for d in $DIRS
>>>     do
>>>         pushd $d
>>>         echo >> Makefile
>>>         for f in *.S
>>>         do
>>>             echo "OBJECT_FILES_NON_STANDARD_$f := y" | sed s/"\.S"/".o"/g
>>>         done >> Makefile
>>>         popd
>>>     done
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>>  arch/powerpc/boot/Makefile                 | 17 +++++++++
>>>  arch/powerpc/crypto/Makefile               | 13 +++++++
>>>  arch/powerpc/kernel/Makefile               | 44 ++++++++++++++++++++++
>>>  arch/powerpc/kernel/trace/Makefile         |  4 ++
>>>  arch/powerpc/kernel/vdso/Makefile          | 11 ++++++
>>>  arch/powerpc/kexec/Makefile                |  2 +
>>>  arch/powerpc/kvm/Makefile                  | 13 +++++++
>>>  arch/powerpc/lib/Makefile                  | 25 ++++++++++++
>>>  arch/powerpc/mm/book3s32/Makefile          |  3 ++
>>>  arch/powerpc/mm/nohash/Makefile            |  3 ++
>>>  arch/powerpc/perf/Makefile                 |  2 +
>>>  arch/powerpc/platforms/44x/Makefile        |  2 +
>>>  arch/powerpc/platforms/52xx/Makefile       |  3 ++
>>>  arch/powerpc/platforms/83xx/Makefile       |  2 +
>>>  arch/powerpc/platforms/cell/spufs/Makefile |  3 ++
>>>  arch/powerpc/platforms/pasemi/Makefile     |  2 +
>>>  arch/powerpc/platforms/powermac/Makefile   |  3 ++
>>>  arch/powerpc/platforms/powernv/Makefile    |  3 ++
>>>  arch/powerpc/platforms/ps3/Makefile        |  2 +
>>>  arch/powerpc/platforms/pseries/Makefile    |  2 +
>>>  arch/powerpc/purgatory/Makefile            |  3 ++
>>>  arch/powerpc/sysdev/Makefile               |  3 ++
>>>  arch/powerpc/xmon/Makefile                 |  3 ++
>>>  23 files changed, 168 insertions(+)
>>>
>> 
>> I think it might be better to have a config option so that architectures 
>> can opt-in to skip objtool on asm files. We can then do:
> 
> Well, the idea here was to initially opt out every file in order to 
> quickly add support for objtool uaccess checking, and then opt-in back 
> files one by one once they are ready for it.

That was my initial thought too.

> 
> In most files,all we have to do is to replace all _GLOBAL() by 
> SYM_FUNC_START(), add a SYM_FUNC_END() at the end of the function, then 
> do the same with SYM_FUNC_START_LOCAL() with all non global functions.
> 
> That's easy to do and worth it but it takes time, hence the idea of an 
> incremental approach.

Right. But until that's done, I am not sure it is worth the churn to the 
Makefiles.

Besides, it isn't clear to me that the existing features we are 
targeting for objtool on powerpc need objtool to run on asm files (so, 
an incremental approach may not really get us much). Objtool --mcount 
doesn't care about .S files.  I suppose uaccess validation also doesn't 
need it. It's likely just stack validation (should we choose to enable 
it) that needs objtool to be run on asm files.

The first patch series converting much of our .S files can drop the 
config option and exclude the remaining files.


- Naveen


  reply	other threads:[~2023-06-20  6:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-16 13:47 [RFC PATCH v1 0/3] powerpc/objtool: First step towards uaccess validation (v1) Christophe Leroy
2023-06-16 13:47 ` [RFC PATCH v1 1/3] Revert "powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto" Christophe Leroy
2023-06-20  5:21   ` Naveen N Rao
2023-06-20  7:10     ` Peter Zijlstra
2023-06-16 13:47 ` [RFC PATCH v1 2/3] powerpc: Mark all .S files invalid for objtool Christophe Leroy
2023-06-20  6:04   ` Naveen N Rao
2023-06-20  6:15     ` Christophe Leroy
2023-06-20  6:40       ` Naveen N Rao [this message]
2023-06-16 13:47 ` [RFC PATCH v1 3/3] powerpc: WIP draft support to objtool check Christophe Leroy
2023-06-16 14:43   ` Peter Zijlstra

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=1687242440.kuukzoknou.naveen@kernel.org \
    --to=naveen@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.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;
as well as URLs for NNTP newsgroup(s).