Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 [EMAIL PROTECTED] --- 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 896..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) + mtlr0 + 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);
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] 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 :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
David Miller wrote: From: Scott Wood [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On Fri, 2008-05-02 at 14:42 -0700, David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
