[PATCH] OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

[PATCH] OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

[Florian Fainelli]

When building with a gcc-4.4.x toolchain that is configured to produce 32-bits
executables by default, we will produce __lshrti3 in sched_clock() which is
never resolved so the kernel fails to link. Unconditionally use the inline
assembly version as suggested by David Daney, which works around the issue.

CC: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/arch/mips/cavium-octeon/csrc-octeon.c b/arch/mips/cavium-octeon/csrc-octeon.c
index 0bf4bbe..36400d2 100644
--- a/arch/mips/cavium-octeon/csrc-octeon.c
+++ b/arch/mips/cavium-octeon/csrc-octeon.c
@@ -53,7 +53,6 @@ static struct clocksource clocksource_mips = {
 unsigned long long notrace sched_clock(void)
 {
 	/* 64-bit arithmatic can overflow, so use 128-bit.  */
-#if (__GNUC__ < 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ <= 3))
 	u64 t1, t2, t3;
 	unsigned long long rv;
 	u64 mult = clocksource_mips.mult;
@@ -73,13 +72,6 @@ unsigned long long notrace sched_clock(void)
 		: [cnt] "r" (cnt), [mult] "r" (mult), [shift] "r" (shift)
 		: "hi", "lo");
 	return rv;
-#else
-	/* GCC > 4.3 do it the easy way.  */
-	unsigned int __attribute__((mode(TI))) t;
-	t = read_c0_cvmcount();
-	t = t * clocksource_mips.mult;
-	return (unsigned long long)(t >> clocksource_mips.shift);
-#endif
 }
 
 void __init plat_time_init(void)

Re: [PATCH] OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

[David Daney]

On 07/28/2010 03:13 PM, Florian Fainelli wrote:
> When building with a gcc-4.4.x toolchain that is configured to produce 32-bits
> executables by default, we will produce __lshrti3 in sched_clock() which is
> never resolved so the kernel fails to link. Unconditionally use the inline
> assembly version as suggested by David Daney, which works around the issue.
>
> CC: David Daney<ddaney@caviumnetworks.com>
> Signed-off-by: Florian Fainelli<florian@openwrt.org>

Acked-by: David Daney <ddaney@caviumnetworks.com>

> ---
> diff --git a/arch/mips/cavium-octeon/csrc-octeon.c b/arch/mips/cavium-octeon/csrc-octeon.c
> index 0bf4bbe..36400d2 100644
> --- a/arch/mips/cavium-octeon/csrc-octeon.c
> +++ b/arch/mips/cavium-octeon/csrc-octeon.c
> @@ -53,7 +53,6 @@ static struct clocksource clocksource_mips = {
>   unsigned long long notrace sched_clock(void)
>   {
>   	/* 64-bit arithmatic can overflow, so use 128-bit.  */
> -#if (__GNUC__<  4) || ((__GNUC__ == 4)&&  (__GNUC_MINOR__<= 3))
>   	u64 t1, t2, t3;
>   	unsigned long long rv;
>   	u64 mult = clocksource_mips.mult;
> @@ -73,13 +72,6 @@ unsigned long long notrace sched_clock(void)
>   		: [cnt] "r" (cnt), [mult] "r" (mult), [shift] "r" (shift)
>   		: "hi", "lo");
>   	return rv;
> -#else
> -	/* GCC>  4.3 do it the easy way.  */
> -	unsigned int __attribute__((mode(TI))) t;
> -	t = read_c0_cvmcount();
> -	t = t * clocksource_mips.mult;
> -	return (unsigned long long)(t>>  clocksource_mips.shift);
> -#endif
>   }
>
>   void __init plat_time_init(void)
>
>
>

Re: [PATCH] OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

[Ralf Baechle]

On Wed, Jul 28, 2010 at 03:15:40PM -0700, David Daney wrote:

> >executables by default, we will produce __lshrti3 in sched_clock() which is
> >never resolved so the kernel fails to link. Unconditionally use the inline
> >assembly version as suggested by David Daney, which works around the issue.
> >
> >CC: David Daney<ddaney@caviumnetworks.com>
> >Signed-off-by: Florian Fainelli<florian@openwrt.org>
> 
> Acked-by: David Daney <ddaney@caviumnetworks.com>

Applied - but maybe we should just add lshrti3 instead?  We already have
ashldi3, ashrdi3 and lshrdi3.

  Ralf

Re: [PATCH] OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

[David Daney]

On 08/02/2010 07:59 AM, Ralf Baechle wrote:
> On Wed, Jul 28, 2010 at 03:15:40PM -0700, David Daney wrote:
>
>>> executables by default, we will produce __lshrti3 in sched_clock() which is
>>> never resolved so the kernel fails to link. Unconditionally use the inline
>>> assembly version as suggested by David Daney, which works around the issue.
>>>
>>> CC: David Daney<ddaney@caviumnetworks.com>
>>> Signed-off-by: Florian Fainelli<florian@openwrt.org>
>>
>> Acked-by: David Daney<ddaney@caviumnetworks.com>
>
> Applied - but maybe we should just add lshrti3 instead?  We already have
> ashldi3, ashrdi3 and lshrdi3.

Too slow I think.  If we are doing 128-bit arithmetic, it should only be 
for tricky things that we are optimizing to go real fast.  In this case, 
we don't want to be making function calls.

Well that is my $0.02

David Daney