[PATCH 3/4] sparc32: return destination pointer on return from memcpy

[PATCH 3/4] sparc32: return destination pointer on return from memcpy

[Konrad Eisele]

Gcc can optimize constant strcpy to a memcpy call. However
the return value of strcpy is used in KGDB. Return the standard return
value instead of 0

Signed-off-by: Konrad Eisele <konrad@gaisler.com>
---
 arch/sparc/lib/memcpy.S |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/sparc/lib/memcpy.S b/arch/sparc/lib/memcpy.S
index 34fe657..835014b 100644
--- a/arch/sparc/lib/memcpy.S
+++ b/arch/sparc/lib/memcpy.S
@@ -19,12 +19,8 @@ x:
 #undef FASTER_NONALIGNED
 #define FASTER_ALIGNED
 
-/* In kernel these functions don't return a value.
- * One should use macros in asm/string.h for that purpose.
- * We return 0, so that bugs are more apparent.
- */
-#define SETUP_RETL
-#define RETL_INSN	clr	%o0
+#define SETUP_RETL	mov	%o0, %g6
+#define RETL_INSN	mov	%g6, %o0
 
 #else
 
-- 
1.6.4.1

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[David Miller]

From: Konrad Eisele <konrad@gaisler.com>
Date: Thu, 13 Oct 2011 09:00:04 +0200

> -/* In kernel these functions don't return a value.
> - * One should use macros in asm/string.h for that purpose.
> - * We return 0, so that bugs are more apparent.
> - */
> -#define SETUP_RETL
> -#define RETL_INSN	clr	%o0
> +#define SETUP_RETL	mov	%o0, %g6
> +#define RETL_INSN	mov	%g6, %o0

Sigh...

The kernel uses %g6 as the global thread register, see
include/asm/thread_info_32.h:

register struct thread_info *current_thread_info_reg asm("g6");

Your kernel would have crashed early in the boot if you actually
tested this patch.

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[Konrad Eisele]

David Miller wrote:
> From: Konrad Eisele <konrad@gaisler.com>
> Date: Thu, 13 Oct 2011 09:00:04 +0200
> 
>> -/* In kernel these functions don't return a value.
>> - * One should use macros in asm/string.h for that purpose.
>> - * We return 0, so that bugs are more apparent.
>> - */
>> -#define SETUP_RETL
>> -#define RETL_INSN	clr	%o0
>> +#define SETUP_RETL	mov	%o0, %g6
>> +#define RETL_INSN	mov	%g6, %o0
> 
> Sigh...
> 
> The kernel uses %g6 as the global thread register, see
> include/asm/thread_info_32.h:
> 
> register struct thread_info *current_thread_info_reg asm("g6");
> 
> Your kernel would have crashed early in the boot if you actually
> tested this patch.
> 
> 

Isnt the simplest way to apply the original gdbstub.c patch instead?

-		ptr += strlen(strcpy(ptr, "thread:"));
+		strcpy(ptr, "thread:");
+		ptr += strlen(ptr);


Or even a simple

		strcpy(ptr, "thread:");
		ptr += 7;

In that case its the
"[PATCH 4/4] kernel,debug: SPARC KGDB stub strcpy fix" from [09/30/2011 03:47 PM].
instead of the memcpy patch.

It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c
diff worth a memcpy rewrite?

-- Konrad

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[David Miller]

From: Konrad Eisele <konrad@gaisler.com>
Date: Wed, 19 Oct 2011 10:33:25 +0200

> Isnt the simplest way to apply the original gdbstub.c patch instead?

It's wrong, memcpy() is not implemented properly on 32-bit sparc, fix
it.

> It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c
> diff worth a memcpy rewrite?

You really can't find another register to save the initial %o0 value in?
Have you even tried?

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[Kjetil Oftedal]

On Wed, 19 Oct 2011, David Miller wrote:

> From: Konrad Eisele <konrad@gaisler.com>
> Date: Wed, 19 Oct 2011 10:33:25 +0200
> 
> > It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c
> > diff worth a memcpy rewrite?
> 
> You really can't find another register to save the initial %o0 value in?
> Have you even tried?

This might be considered a ugly hack. But what about using %y ? According 
to the V8 manual, %y might be destroyed across a procedure call, and none 
of the functions in memcpy.S use multiply/divide instructions. It is 
however not mentioned as a available register in the section dealing with 
leaf procedures. 

A quick test on a SS20 did not reveal any immediate side-effects, and 
the return value of memcpy is now the destination pointer.

---
diff --git a/arch/sparc/lib/memcpy.S b/arch/sparc/lib/memcpy.S
index 34fe657..0327309 100644
--- a/arch/sparc/lib/memcpy.S
+++ b/arch/sparc/lib/memcpy.S
@@ -23,8 +23,8 @@ x:
  * One should use macros in asm/string.h for that purpose.
  * We return 0, so that bugs are more apparent.
  */
-#define SETUP_RETL
-#define RETL_INSN      clr     %o0
+#define SETUP_RETL     mov     %o0, %y
+#define RETL_INSN      mov     %y, %o0
 
 #else

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[David Miller]

From: Kjetil Oftedal <oftedal@gmail.com>
Date: Wed, 19 Oct 2011 23:11:29 +0200 (CEST)

> On Wed, 19 Oct 2011, David Miller wrote:
> 
>> From: Konrad Eisele <konrad@gaisler.com>
>> Date: Wed, 19 Oct 2011 10:33:25 +0200
>> 
>> > It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c
>> > diff worth a memcpy rewrite?
>> 
>> You really can't find another register to save the initial %o0 value in?
>> Have you even tried?
> 
> This might be considered a ugly hack. But what about using %y ? According 
> to the V8 manual, %y might be destroyed across a procedure call, and none 
> of the functions in memcpy.S use multiply/divide instructions. It is 
> however not mentioned as a available register in the section dealing with 
> leaf procedures. 
> 
> A quick test on a SS20 did not reveal any immediate side-effects, and 
> the return value of memcpy is now the destination pointer.

Never mind, I'll work on this myself.  Trying to get you to implement
this properly is hopeless.  Writing to and reading from the %y
register is extremely expensive compared to a regular register.

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[Konrad Eisele]

David Miller wrote:
> From: Kjetil Oftedal <oftedal@gmail.com>
> Date: Wed, 19 Oct 2011 23:11:29 +0200 (CEST)
> 
>> On Wed, 19 Oct 2011, David Miller wrote:
>>
>>> From: Konrad Eisele <konrad@gaisler.com>
>>> Date: Wed, 19 Oct 2011 10:33:25 +0200
>>>
>>>> It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c
>>>> diff worth a memcpy rewrite?
>>>
>>> You really can't find another register to save the initial %o0 value in?
>>> Have you even tried?
>>
>> This might be considered a ugly hack. But what about using %y ? According 
>> to the V8 manual, %y might be destroyed across a procedure call, and none 
>> of the functions in memcpy.S use multiply/divide instructions. It is 
>> however not mentioned as a available register in the section dealing with 
>> leaf procedures. 
>>
>> A quick test on a SS20 did not reveal any immediate side-effects, and 
>> the return value of memcpy is now the destination pointer.
> 
> Never mind, I'll work on this myself.  Trying to get you to implement
> this properly is hopeless.  Writing to and reading from the %y
> register is extremely expensive compared to a regular register.
> 
> 

Sorry to make you angry but, yes, I looked weather all registers are taken,
and yes, memcpy is very compact programmed. The %g6 patch was a mistake, sorry.
-- Konrad

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[David Miller]

From: Konrad Eisele <konrad@gaisler.com>
Date: Thu, 20 Oct 2011 08:59:15 +0200

> Sorry to make you angry but, yes, I looked weather all registers are taken,
> and yes, memcpy is very compact programmed.

It took me 10 minutes to code up a fix.

Re: [PATCH 3/4] sparc32: return destination pointer on return from

[Konrad Eisele]

David Miller wrote:
> From: Konrad Eisele <konrad@gaisler.com>
> Date: Thu, 20 Oct 2011 08:59:15 +0200
> 
>> Sorry to make you angry but, yes, I looked weather all registers are taken,
>> and yes, memcpy is very compact programmed.
> 
> It took me 10 minutes to code up a fix.
> 
> 

That speaks for you.