login
Search
We have a number of functions which return small structures (such as
pte_t). It seems that the kernel is not compiled with
-freg-struct-return, so all these small structures are being returned
via the stack, even though they would fit into registers.
Is there a reason for this? Would -freg-struct-return be preferred? It
would make a good compliment to -mregparm.
J
-
Do we know how many gcc bugs this has? (regparm used to have many) other than that.. sounds like a win... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
The documentation suggests that its the preferred mode of operation, and
that its the default on platforms where gcc is the primary compiler. So
the fact that it isn't for Linux suggests either an oversight or that it
is actually broken...
Do we have much assembler which cares about the struct return calling
convention? If not, it should be a fairly easy test.
J
-
is there an attribute to turn it off? because if so we should just make that part of "asmlinkage".... (not that I know much code using structs in asm) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
There doesn't appear to be; just -freg-struct-return and
-fpcc-struct-return.
J
-
Subject: [patch] x86: add -freg-struct-return to CFLAGS
From: Ingo Molnar <mingo@elte.hu>
Jeremy Fitzhardinge suggested the use of -freg-struct-return, which does
structure-returns (such as when using pte_t) in registers instead of on
the stack.
that is indeed so, and this option reduced the kernel size a bit:
text data bss dec hex filename
4799506 543456 3760128 9103090 8ae6f2 vmlinux.before
4798117 543456 3760128 9101701 8ae185 vmlinux.after
the resulting kernel booted fine on my testbox. Lets go for it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/i386/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/i386/Makefile
===================================================================
--- linux.orig/arch/i386/Makefile
+++ linux/arch/i386/Makefile
@@ -31,7 +31,7 @@ LDFLAGS_vmlinux := --emit-relocs
endif
CHECKFLAGS += -D__i386__
-CFLAGS += -pipe -msoft-float -mregparm=3
+CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return
# prevent gcc from keeping the stack 16 byte aligned
CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
-
Ok I added it for now. Let's see what happens. I guess people maintaining external Makefiles without Kbuild are in for a nasty surprise again though. Cannot be avoided unfortunately. -Andi -
that 1) shouldn't be needed at all for 2.6 and 2) is fragile as heck no matter, I don't think anyone still is doing that... I sure hope that if anyone still does it that they have no users at all, for the sake of the users :) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -
Why is this i386 specific?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Because virtually all other architectures have it as their ABI default, anyway, and ABI selection should be per architecture. -hpa -
It is used for Linux on many architectures (x86_64, sparc64, ia64,
ppc{,64}, arm, sh, m68k to name just a few), but it is an ABI decision,
so e.g. on i386 is not used by default as the ABI mandates structs/unions
are returned in memory.
Jakub
-
Sometimes returning small structures is really nice. If you can pass them in registers, it's often generates the fastest possible code; much better than using a pointer. -hpa -
Yes, but specifically, are there any pieces of assembler which return
structures? It appears there are none (since Ingo got a booting
kernel), but there might be something obscure in some corner.
J
-
When I did the x86-64 port I went over all assembler and I can't remember anything that did that. Of course there might be out of tree drivers that do, but they just have to fix it up. BTW would it make sense to have a special announcement list for such changes? -Andi -
linux-arch is only for architecture code, but yes it serves a similar purpose. But it's very specialized. What is discussed there is unlikely to be of much interest to most people. I was thinking of a relatively low volume list where quick notes for any general interfaces changes that likely needs adaptions in a wide range of code could be sent. Then even people who cannot follow l-k or git due to volume could subscribe to that and adapt their code as needed. -Andi -
A changelog in the kernel tree would be helpful. A real changelog that is, not that info blob located at /Documentation/Changes. Jan -- -
I presume you're talking about a BSD-style ChangeLog. I've always found those utterly useless, since they're basically the equivalent of SCM history but without any of the abilities to sort, filter, etc, thus making it utterly impossible to find anything. They're a pain to maintain (they inherently *always* cause merge failures) and add very little. -hpa -
