[PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates

[PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates

[Sam Ravnborg]

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(-)

Re: [PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates

[Sam Ravnborg]

On Fri, Apr 22, 2016 at 07:37:12PM +0200, Sam Ravnborg wrote:
> 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.
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

Re: [PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates

[David Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Fri, 22 Apr 2016 19:37:12 +0200

> 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?

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, %o0
  
The 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.

> 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.