sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates
cover sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates
A few cosmetic pathes for sparc32 follows.
I noticed some inconsistency in kgdb_32 that triggered a few patches. The inconsistency in kgdb_32 turned out to have no functional impact. But I anyway fixed it so kgdb_32 and kgdb_64 became just a tiny bit more alike.
The STRICT_MM_TYPECHECKS patch was triggered by a discussion on linux-arch where Arnd considered removing this cruft.
The resulting benary of srmmu.c (I checked an assembler file) was _smaller_ when I defined STRICT_MM_TYPECHECKS. But due to lack of testing I left it undefined. With the build errors fixed it should be trivial to try out if defining STRICT_MM_TYPECHECKS breaks anything.
Any takers?
As I miss any working sparc32 gear for the moment this has only been build tested - so please consider if it is worth taking the risk to apply the patches.
Sam
Sam Ravnborg (5):
sparc32: drop hardcoding trap_level in kgdb_trap
sparc32: drop local prototype in kgdb_32
sparc32: use proper prototype for trapbase
sparc32: fix build with STRICT_MM_TYPECHECKS
sparc32: drop superfluous cast in calls to __nocache_pa()
arch/sparc/include/asm/head_32.h | 8 ++++---- arch/sparc/include/asm/kgdb.h | 2 +- arch/sparc/include/asm/page_32.h | 2 -- arch/sparc/include/asm/pgalloc_32.h | 4 ++-- arch/sparc/include/asm/pgtable_32.h | 2 +- arch/sparc/kernel/entry.S | 10 ++++------ arch/sparc/kernel/kernel.h | 1 + arch/sparc/kernel/kgdb_32.c | 11 +++++------ arch/sparc/kernel/setup_32.c | 4 +--- arch/sparc/mm/io-unit.c | 4 ++-- arch/sparc/mm/srmmu.c | 19 ++++++++++++------- 11 files changed, 33 insertions(+), 34 deletions(-)
Quoted 5 lines · Sam Ravnborg
A few cosmetic pathes for sparc32 follows.
I noticed some inconsistency inkgdb_32that triggered a few patches. The inconsistency inkgdb_32turned out to have no functional impact. But I anyway fixed it sokgdb_32andkgdb_64became just a tiny bit more alike.
This is btw v2 of "sparc32: fix trap number in call to kgdb_handle_exception" posted a few weeks ago.
Should have mentioned that in the original cover letter.
Sam
From: Sam Ravnborg <[email protected]>
Date: Fri, 22 Apr 2016 19:37:12 +0200
Quoted 15 lines
A few cosmetic pathes for sparc32 follows.
I noticed some inconsistency inkgdb_32that triggered a few patches. The inconsistency inkgdb_32turned out to have no functional impact. But I anyway fixed it sokgdb_32andkgdb_64became just a tiny bit more alike.The
STRICT_MM_TYPECHECKSpatch was triggered by a discussion on linux-arch where Arnd considered removing this cruft.
The resulting benary ofsrmmu.c(I checked an assembler file) was _smaller_ when I definedSTRICT_MM_TYPECHECKS. But due to lack of testing I left it undefined. With the build errors fixed it should be trivial to try out if definingSTRICT_MM_TYPECHECKSbreaks anything.
Quoted 1 line
Any takers?
Maybe the binary is smaller, but some things will undoubtedly be slower.
Any non-inline function that returns a pte_t, pmd_t, or any other of these types will do so by indirect reference.
It'll look something like this:
ld [%sp+64], %g1
st %o0, [%g1]
jmp %o7+12
mov %g1, %o0The caller allocates a stack slot, the callee stores into that stack slot and returns to an address one extra instruction past the usual return address.
The reason for the weird return, is that the normal return address has a special "unimp" instruction that encodes the size of the object is expects the callee to return.
Anyways, it's not very efficient. Especially for an aggregate which is just a single word in size. sparc64's calling conventions handle this much better by just directly returning the value in register(s).
I really wouldn't want to turn this on unless it really holds back a lot of other platforms for some reason.
Quoted 3 lines
As I miss any working sparc32 gear for the moment this has only been build tested - so please consider if it is worth taking the risk to apply the patches.
This series looks great, all applied, thanks Sam.