[PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Kumar Gala]

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the kernel build as we'd have to link with libgcc to get the
implementation of the register save/restores.

To workaround this issue, we just stole the save/restore code from gcc
and simplified it down for our needs (integer only).  We only do this if
PPC32 as gcc makes believe the linker on ppc64 will deal with this and
only if CONFIG_CC_OPTIMIZE_FOR_SIZE is set (thus -Os).

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

If someone using cutting edge toolchains for ppc64 could test and make
sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be
nice.

- k

 arch/powerpc/kernel/misc_32.S   |   77 +++++++++++++++++++++++++++
 arch/powerpc/kernel/ppc_ksyms.c |  111 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 188 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 89aaaa6..651eac0 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -974,3 +974,80 @@ relocate_new_kernel_end:
 relocate_new_kernel_size:
 	.long relocate_new_kernel_end - relocate_new_kernel
 #endif
+
+#if defined(CONFIG_PPC32) && defined(CONFIG_CC_OPTIMIZE_FOR_SIZE)
+/* Routines for saving integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer save area.  */
+
+_GLOBAL(_savegpr_14)	stw	14,-72(11)	/* save gp registers */
+_GLOBAL(_savegpr_15)	stw	15,-68(11)
+_GLOBAL(_savegpr_16)	stw	16,-64(11)
+_GLOBAL(_savegpr_17)	stw	17,-60(11)
+_GLOBAL(_savegpr_18)	stw	18,-56(11)
+_GLOBAL(_savegpr_19)	stw	19,-52(11)
+_GLOBAL(_savegpr_20)	stw	20,-48(11)
+_GLOBAL(_savegpr_21)	stw	21,-44(11)
+_GLOBAL(_savegpr_22)	stw	22,-40(11)
+_GLOBAL(_savegpr_23)	stw	23,-36(11)
+_GLOBAL(_savegpr_24)	stw	24,-32(11)
+_GLOBAL(_savegpr_25)	stw	25,-28(11)
+_GLOBAL(_savegpr_26)	stw	26,-24(11)
+_GLOBAL(_savegpr_27)	stw	27,-20(11)
+_GLOBAL(_savegpr_28)	stw	28,-16(11)
+_GLOBAL(_savegpr_29)	stw	29,-12(11)
+_GLOBAL(_savegpr_30)	stw	30,-8(11)
+_GLOBAL(_savegpr_31)	stw	31,-4(11)
+			blr
+
+/* Routines for restoring integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area.  */
+
+_GLOBAL(_restgpr_14)	lwz	14,-72(11)	/* restore gp registers */
+_GLOBAL(_restgpr_15)	lwz	15,-68(11)
+_GLOBAL(_restgpr_16)	lwz	16,-64(11)
+_GLOBAL(_restgpr_17)	lwz	17,-60(11)
+_GLOBAL(_restgpr_18)	lwz	18,-56(11)
+_GLOBAL(_restgpr_19)	lwz	19,-52(11)
+_GLOBAL(_restgpr_20)	lwz	20,-48(11)
+_GLOBAL(_restgpr_21)	lwz	21,-44(11)
+_GLOBAL(_restgpr_22)	lwz	22,-40(11)
+_GLOBAL(_restgpr_23)	lwz	23,-36(11)
+_GLOBAL(_restgpr_24)	lwz	24,-32(11)
+_GLOBAL(_restgpr_25)	lwz	25,-28(11)
+_GLOBAL(_restgpr_26)	lwz	26,-24(11)
+_GLOBAL(_restgpr_27)	lwz	27,-20(11)
+_GLOBAL(_restgpr_28)	lwz	28,-16(11)
+_GLOBAL(_restgpr_29)	lwz	29,-12(11)
+_GLOBAL(_restgpr_30)	lwz	30,-8(11)
+_GLOBAL(_restgpr_31)	lwz	31,-4(11)
+			blr
+
+/* Routines for restoring integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area.  */
+
+_GLOBAL(_restgpr_14_x)	lwz	14,-72(11)	/* restore gp registers */
+_GLOBAL(_restgpr_15_x)	lwz	15,-68(11)
+_GLOBAL(_restgpr_16_x)	lwz	16,-64(11)
+_GLOBAL(_restgpr_17_x)	lwz	17,-60(11)
+_GLOBAL(_restgpr_18_x)	lwz	18,-56(11)
+_GLOBAL(_restgpr_19_x)	lwz	19,-52(11)
+_GLOBAL(_restgpr_20_x)	lwz	20,-48(11)
+_GLOBAL(_restgpr_21_x)	lwz	21,-44(11)
+_GLOBAL(_restgpr_22_x)	lwz	22,-40(11)
+_GLOBAL(_restgpr_23_x)	lwz	23,-36(11)
+_GLOBAL(_restgpr_24_x)	lwz	24,-32(11)
+_GLOBAL(_restgpr_25_x)	lwz	25,-28(11)
+_GLOBAL(_restgpr_26_x)	lwz	26,-24(11)
+_GLOBAL(_restgpr_27_x)	lwz	27,-20(11)
+_GLOBAL(_restgpr_28_x)	lwz	28,-16(11)
+_GLOBAL(_restgpr_29_x)	lwz	29,-12(11)
+_GLOBAL(_restgpr_30_x)	lwz	30,-8(11)
+_GLOBAL(_restgpr_31_x)	lwz	0,4(11)
+			lwz	31,-4(11)
+			mtlr	0
+			mr	1,11
+			blr
+#endif
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index cf6b5a7..a165ef0 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -185,3 +185,114 @@ EXPORT_SYMBOL(__mtdcr);
 EXPORT_SYMBOL(__mfdcr);
 #endif
 EXPORT_SYMBOL(empty_zero_page);
+
+#if defined(CONFIG_PPC32) && defined(CONFIG_CC_OPTIMIZE_FOR_SIZE)
+void _savegpr_14(void);
+void _savegpr_15(void);
+void _savegpr_16(void);
+void _savegpr_17(void);
+void _savegpr_18(void);
+void _savegpr_19(void);
+void _savegpr_20(void);
+void _savegpr_21(void);
+void _savegpr_22(void);
+void _savegpr_23(void);
+void _savegpr_24(void);
+void _savegpr_25(void);
+void _savegpr_26(void);
+void _savegpr_27(void);
+void _savegpr_28(void);
+void _savegpr_29(void);
+void _savegpr_30(void);
+void _savegpr_31(void);
+void _restgpr_14(void);
+void _restgpr_15(void);
+void _restgpr_16(void);
+void _restgpr_17(void);
+void _restgpr_18(void);
+void _restgpr_19(void);
+void _restgpr_20(void);
+void _restgpr_21(void);
+void _restgpr_22(void);
+void _restgpr_23(void);
+void _restgpr_24(void);
+void _restgpr_25(void);
+void _restgpr_26(void);
+void _restgpr_27(void);
+void _restgpr_28(void);
+void _restgpr_29(void);
+void _restgpr_30(void);
+void _restgpr_31(void);
+void _restgpr_14_x(void);
+void _restgpr_15_x(void);
+void _restgpr_16_x(void);
+void _restgpr_17_x(void);
+void _restgpr_18_x(void);
+void _restgpr_19_x(void);
+void _restgpr_20_x(void);
+void _restgpr_21_x(void);
+void _restgpr_22_x(void);
+void _restgpr_23_x(void);
+void _restgpr_24_x(void);
+void _restgpr_25_x(void);
+void _restgpr_26_x(void);
+void _restgpr_27_x(void);
+void _restgpr_28_x(void);
+void _restgpr_29_x(void);
+void _restgpr_30_x(void);
+void _restgpr_31_x(void);
+EXPORT_SYMBOL(_savegpr_14);
+EXPORT_SYMBOL(_savegpr_15);
+EXPORT_SYMBOL(_savegpr_16);
+EXPORT_SYMBOL(_savegpr_17);
+EXPORT_SYMBOL(_savegpr_18);
+EXPORT_SYMBOL(_savegpr_19);
+EXPORT_SYMBOL(_savegpr_20);
+EXPORT_SYMBOL(_savegpr_21);
+EXPORT_SYMBOL(_savegpr_22);
+EXPORT_SYMBOL(_savegpr_23);
+EXPORT_SYMBOL(_savegpr_24);
+EXPORT_SYMBOL(_savegpr_25);
+EXPORT_SYMBOL(_savegpr_26);
+EXPORT_SYMBOL(_savegpr_27);
+EXPORT_SYMBOL(_savegpr_28);
+EXPORT_SYMBOL(_savegpr_29);
+EXPORT_SYMBOL(_savegpr_30);
+EXPORT_SYMBOL(_savegpr_31);
+EXPORT_SYMBOL(_restgpr_14);
+EXPORT_SYMBOL(_restgpr_15);
+EXPORT_SYMBOL(_restgpr_16);
+EXPORT_SYMBOL(_restgpr_17);
+EXPORT_SYMBOL(_restgpr_18);
+EXPORT_SYMBOL(_restgpr_19);
+EXPORT_SYMBOL(_restgpr_20);
+EXPORT_SYMBOL(_restgpr_21);
+EXPORT_SYMBOL(_restgpr_22);
+EXPORT_SYMBOL(_restgpr_23);
+EXPORT_SYMBOL(_restgpr_24);
+EXPORT_SYMBOL(_restgpr_25);
+EXPORT_SYMBOL(_restgpr_26);
+EXPORT_SYMBOL(_restgpr_27);
+EXPORT_SYMBOL(_restgpr_28);
+EXPORT_SYMBOL(_restgpr_29);
+EXPORT_SYMBOL(_restgpr_30);
+EXPORT_SYMBOL(_restgpr_31);
+EXPORT_SYMBOL(_restgpr_14_x);
+EXPORT_SYMBOL(_restgpr_15_x);
+EXPORT_SYMBOL(_restgpr_16_x);
+EXPORT_SYMBOL(_restgpr_17_x);
+EXPORT_SYMBOL(_restgpr_18_x);
+EXPORT_SYMBOL(_restgpr_19_x);
+EXPORT_SYMBOL(_restgpr_20_x);
+EXPORT_SYMBOL(_restgpr_21_x);
+EXPORT_SYMBOL(_restgpr_22_x);
+EXPORT_SYMBOL(_restgpr_23_x);
+EXPORT_SYMBOL(_restgpr_24_x);
+EXPORT_SYMBOL(_restgpr_25_x);
+EXPORT_SYMBOL(_restgpr_26_x);
+EXPORT_SYMBOL(_restgpr_27_x);
+EXPORT_SYMBOL(_restgpr_28_x);
+EXPORT_SYMBOL(_restgpr_29_x);
+EXPORT_SYMBOL(_restgpr_30_x);
+EXPORT_SYMBOL(_restgpr_31_x);
+#endif /* CONFIG_PPC32 && CONFIG_CC_OPTIMIZE_FOR_SIZE */
-- 
1.5.4.1

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Scott Wood]

On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote:
> GCC 4.4.x looks to be adding support for generating out-of-line register
> saves/restores based on:
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
> 
> This breaks the kernel build as we'd have to link with libgcc to get the
> implementation of the register save/restores.

<brokenrecord>
Why don't we just link with libgcc?
</brokenrecord>

-Scott

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Kumar Gala]

On May 2, 2008, at 10:07 AM, Scott Wood wrote:

> On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote:
>> GCC 4.4.x looks to be adding support for generating out-of-line  
>> register
>> saves/restores based on:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
>>
>> This breaks the kernel build as we'd have to link with libgcc to  
>> get the
>> implementation of the register save/restores.
>
> <brokenrecord>
> Why don't we just link with libgcc?
> </brokenrecord>

Its something of a PITA to do that in the kernel at this point since  
we've duplicated libgcc functionality in it.  I'm sure there are some  
historical reasons this wasn't done to start with.

- k

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Segher Boessenkool]

> If someone using cutting edge toolchains for ppc64 could test and make
> sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be
> nice.

Current linus tree + some more stuff + this patch, ppc64_defconfig,
powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just
fine.  CONFIG_CC_OPTIMIZE_FOR_SIZE=y.  Need any more test / more info?


Segher

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Segher Boessenkool]

>> <brokenrecord>
>> Why don't we just link with libgcc?
>> </brokenrecord>
>
> Its something of a PITA to do that in the kernel at this point since 
> we've duplicated libgcc functionality in it.  I'm sure there are some 
> historical reasons this wasn't done to start with.

That's the same as saying that it would be a nice cleanup to remove all
that duplicated code now...


Segher

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Kumar Gala]

On May 2, 2008, at 12:33 PM, Segher Boessenkool wrote:

>> If someone using cutting edge toolchains for ppc64 could test and  
>> make
>> sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that  
>> would be
>> nice.
>
> Current linus tree + some more stuff + this patch, ppc64_defconfig,
> powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just
> fine.  CONFIG_CC_OPTIMIZE_FOR_SIZE=y.  Need any more test / more info?

I don't think the gcc guys have accepted (or committed) the patch I  
was referencing.  Once it has been we should retest and see what  
happens.

- k

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Kumar Gala]

On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:

>>> <brokenrecord>
>>> Why don't we just link with libgcc?
>>> </brokenrecord>
>>
>> Its something of a PITA to do that in the kernel at this point  
>> since we've duplicated libgcc functionality in it.  I'm sure there  
>> are some historical reasons this wasn't done to start with.
>
> That's the same as saying that it would be a nice cleanup to remove  
> all
> that duplicated code now...

We'll hopefully this thread might spark either an explanation for why  
we aren't just linking libgcc in a statement that says we should and  
we can remove the code that implements libgcc functionality.

How would libgcc linking intermix with modules?  Would we have to  
EXPORT_SYMBOL() all functions that libgcc implements?  I'm guessing  
that's varies w/different gcc versions.

- k

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Scott Wood]

Kumar Gala wrote:
> 
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
> 
>>>> <brokenrecord>
>>>> Why don't we just link with libgcc?
>>>> </brokenrecord>
>>>
>>> Its something of a PITA to do that in the kernel at this point since 
>>> we've duplicated libgcc functionality in it.  I'm sure there are some 
>>> historical reasons this wasn't done to start with.
>>
>> That's the same as saying that it would be a nice cleanup to remove all
>> that duplicated code now...
> 
> We'll hopefully this thread might spark either an explanation for why we 
> aren't just linking libgcc in a statement that says we should and we can 
> remove the code that implements libgcc functionality.
> 
> How would libgcc linking intermix with modules?  Would we have to 
> EXPORT_SYMBOL() all functions that libgcc implements? 

Yes, unfortunately.

A quick way to generate such a list would be to build a non-modular 
kernel and leave out the libgcc link (after removing the reimplemented 
functions), and see what linker errors you get.

 > I'm guessing that's varies w/different gcc versions.

Yeah, but so does the set of functions that Linux needs to reimplement.

-Scott

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[David Miller]

From: Kumar Gala <galak@kernel.crashing.org>
Date: Fri, 2 May 2008 16:34:13 -0500

> We'll hopefully this thread might spark either an explanation for why  
> we aren't just linking libgcc in a statement that says we should and  
> we can remove the code that implements libgcc functionality.
> 
> How would libgcc linking intermix with modules?  Would we have to  
> EXPORT_SYMBOL() all functions that libgcc implements?  I'm guessing  
> that's varies w/different gcc versions.

If you link in libgcc, all of a sudden you have a whole new class of
potential problems, don't do it.

All it takes is one of these libgcc libcalls the kernel actually
references, needing something else in libc, to make this exercise
futile.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Scott Wood]

David Miller wrote:
> If you link in libgcc, all of a sudden you have a whole new class of
> potential problems, don't do it.
> 
> All it takes is one of these libgcc libcalls the kernel actually
> references, needing something else in libc, to make this exercise
> futile.

What in libgcc references libc, and why isn't this a problem for 
Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that 
use libgcc?

-Scott

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 16:45:45 -0500

> David Miller wrote:
> > If you link in libgcc, all of a sudden you have a whole new class of
> > potential problems, don't do it.
> > 
> > All it takes is one of these libgcc libcalls the kernel actually
> > references, needing something else in libc, to make this exercise
> > futile.
> 
> What in libgcc references libc, and why isn't this a problem for 
> Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that 
> use libgcc?

The problem only occurs once you reference a function that references
libc stuff, and those guys are just lucky so far.

It's also one less variable to debug if you put the implementation
in the kernel, or do you like debugging compiler induced problems?
I don't :-)

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Scott Wood]

David Miller wrote:
> The problem only occurs once you reference a function that references
> libc stuff, and those guys are just lucky so far.

Yeah, lucky they don't need to reinvent the wheel every time the 
GCC/libgcc interface changes. :-)

If GCC generates a call to a libgcc function that calls a libc function, 
I'd consider that a pretty serious bug, given that said libc function is 
likely to consist of GCC-generated code, which could call the same 
libgcc function, which calls the libc function, etc.

> It's also one less variable to debug if you put the implementation
> in the kernel, or do you like debugging compiler induced problems?
> I don't :-)

I'd say problems are more likely if you use nonstandard implementations 
of GCC internals...

-Scott

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 17:16:07 -0500

> If GCC generates a call to a libgcc function that calls a libc function, 
> I'd consider that a pretty serious bug, given that said libc function is 
> likely to consist of GCC-generated code, which could call the same 
> libgcc function, which calls the libc function, etc.

Not really, there are several interfaces in libgcc that need some
runtime help from the C library or the dynamic linker.

For example, EH frame support.

You really don't know what you're talking about.

> I'd say problems are more likely if you use nonstandard implementations 
> of GCC internals...

The kernel is a special environment.  Therefore even if you start
linking with libgcc, it is inevitable that you will need some
changed local version for some of those routines in the kernel.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Scott Wood]

David Miller wrote:
> From: Scott Wood <scottwood@freescale.com>
> Date: Fri, 02 May 2008 17:16:07 -0500
> 
>> If GCC generates a call to a libgcc function that calls a libc function, 
>> I'd consider that a pretty serious bug, given that said libc function is 
>> likely to consist of GCC-generated code, which could call the same 
>> libgcc function, which calls the libc function, etc.
> 
> Not really, there are several interfaces in libgcc that need some
> runtime help from the C library or the dynamic linker.
> 
> For example, EH frame support.

...which is in libgcc_eh, not libgcc, and is in support of features not 
found in the language that libc is implemented in, avoiding any 
possibility of a cyclic dependency.  And the sort of libc functions it 
uses are basic, standard things like memcpy and malloc.  Much easier and 
more stable to implement than the internal libgcc interface.

> You really don't know what you're talking about.

Yawn.

>> I'd say problems are more likely if you use nonstandard implementations 
>> of GCC internals...
> 
> The kernel is a special environment.  Therefore even if you start
> linking with libgcc, it is inevitable that you will need some
> changed local version for some of those routines in the kernel.

Such as?

-Scott

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[David Miller]

From: Scott Wood <scottwood@freescale.com>
Date: Fri, 02 May 2008 17:38:21 -0500

> David Miller wrote:
> > The kernel is a special environment.  Therefore even if you start
> > linking with libgcc, it is inevitable that you will need some
> > changed local version for some of those routines in the kernel.
> 
> Such as?

When I added the software multiply and divide implemenations
to the 32-bit sparc port, I ended up using a different software
trap for signalling divide by zero in the handler so that it
was easier to detect the "from kernel" kernel case.

We're not talking about big complicated routines, we're talking about
quite simple stubs whose interfaces really are not going to change.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Benjamin Herrenschmidt]

On Fri, 2008-05-02 at 16:34 -0500, Kumar Gala wrote:
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
> 
> >>> <brokenrecord>
> >>> Why don't we just link with libgcc?
> >>> </brokenrecord>
> >>
> >> Its something of a PITA to do that in the kernel at this point  
> >> since we've duplicated libgcc functionality in it.  I'm sure there  
> >> are some historical reasons this wasn't done to start with.
> >
> > That's the same as saying that it would be a nice cleanup to remove  
> > all
> > that duplicated code now...
> 
> We'll hopefully this thread might spark either an explanation for why  
> we aren't just linking libgcc in a statement that says we should and  
> we can remove the code that implements libgcc functionality.
> 
> How would libgcc linking intermix with modules?  Would we have to  
> EXPORT_SYMBOL() all functions that libgcc implements?  I'm guessing  
> that's varies w/different gcc versions.

The historical reason for not linking with libgcc was around the lines
of "we want to catch when people do stupid things like 64 bits divides
in the kernel".

Nowadays, this is mostly moot and it's accepted that things might want
to do such operations here or there.

I personally don't see any problem with a patch that would make us link
with libgcc and get rid of the hacks.

Ben.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Benjamin Herrenschmidt]

On Fri, 2008-05-02 at 14:42 -0700, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Fri, 2 May 2008 16:34:13 -0500
> 
> > We'll hopefully this thread might spark either an explanation for why  
> > we aren't just linking libgcc in a statement that says we should and  
> > we can remove the code that implements libgcc functionality.
> > 
> > How would libgcc linking intermix with modules?  Would we have to  
> > EXPORT_SYMBOL() all functions that libgcc implements?  I'm guessing  
> > that's varies w/different gcc versions.
> 
> If you link in libgcc, all of a sudden you have a whole new class of
> potential problems, don't do it.
> 
> All it takes is one of these libgcc libcalls the kernel actually
> references, needing something else in libc, to make this exercise
> futile.

Hrm... I though you linked it in, I must be confusing with another
arch :-) Oh well, if we fail with something pulling bits off libc etc...
we'll see quickly who is the culprit no ?

Ben.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Segher Boessenkool]

>> What in libgcc references libc, and why isn't this a problem for
>> Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs 
>> that
>> use libgcc?
>
> The problem only occurs once you reference a function that references
> libc stuff, and those guys are just lucky so far.

The only calls to the C library that GCC ever generates by itself
(for freestanding mode, at least) are calls to memcmp, memcpy, memmove,
memset (and abort, in some circumstances).  This is true whether or
not you link to libgcc.

> It's also one less variable to debug if you put the implementation
> in the kernel, or do you like debugging compiler induced problems?
> I don't :-)

On the other hand, if we opt to re-implement, we have to make sure
the in-kernel version of the GCC support routines is correct.  We
have to trust the compiler everywhere else already, why not here as
well?


Segher

p.s.  I just finished some testing linking a powerpc kernel with
libgcc.  All went fine, as expected.  I also did a stupid test that
actually needed a libgcc routine (__udivdi3); that went fine as well.
And yeah, I know about the modules issue, but that isn't really very
different from the analogue issue with in-kernel library routines.

Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Paul Mackerras]

Kumar Gala writes:

> We'll hopefully this thread might spark either an explanation for why  
> we aren't just linking libgcc in a statement that says we should and  
> we can remove the code that implements libgcc functionality.

I've just reviewed the code in the 32-bit and 64-bit PowerPC versions
of libgcc.  It's pretty huge (half a megabyte or so in total) but
fortunately most of the bulk is in the decimal floating-point support,
which I largely ignored (though I did notice in passing that it calls
libc functions including strchr, strtof, and sprintf).

On 64-bit I don't see anything there that I would expect we would
need.  There are some things that are in there because some processors
have particular instructions that others don't, for example popcountb
(which is in the V2.05 architecture but not earlier versions), so gcc
can generate either the instruction or a call to the libgcc function,
depending on what sort of processor you're compiling for.  However, in
those cases, we'd want our own version of the libgcc function so that
we could use our CPU feature mechanism to give us the new instruction
on those CPUs that have it.

On 32-bit, it's pretty much just the 64-bit arithmetic routines that
we would need from libgcc (shifts, compares, multiply, divide,
modulo).  I'm not too impressed with the quality of the code there,
for example, the 64-bit signed divide routine is 299 instructions,
which seems enormous to me.  It's all generated from portable C code
by gcc.  I think I can do a smaller and faster 64-bit divide routine
in assembler, for instance.

So on the whole I don't think we want to link with libgcc, although I
don't feel very strongly about it.

Paul.