View previous topic :: View next topic |
Author |
Message |
dete n00b
Joined: 07 Dec 2004 Posts: 10
|
Posted: Tue Dec 07, 2004 5:04 pm Post subject: I want mregparm! |
|
|
I know that adding -mregparm=3 to my CFLAGS will break compatibility with any binary libraries/applications. But I also know that I'm gonna compile everything I put on this machine, and regparm is cool.
However!
When I'm trying to bootstrap, I'm running into the problem that the config scripts invoke the compiler with my CFLAGS, and the bootstrap CD is built without regparm... things get haywire.
Specifically, when glibc is being built, it compiles lots of little programs to determine things -- for example, the size of a long double. However, it checks the status code on those programs and the return codes are bogus if I use regparm. (On my machine, the status for every tool compiled with regparm is 80.)
So, has anyone ever gotten mregparm=3 to work globally in CFLAGS.
If not, does anyone have any tips? Seems to me the best option would be if there was some way of specifying flags used for building, but ignored for config, but that seems unlikely. Any other ideas? Would it be possible to build a bootstrap CD with -mregparm=3, or will I run into the same problem? Is there some way I can tell every little config tool to use exit(code)? instead of return code;? (Would that even help?)
Any tips and discussion are appreciated! |
|
Back to top |
|
|
racoontje Veteran
Joined: 19 Jul 2004 Posts: 1290
|
Posted: Tue Dec 07, 2004 7:32 pm Post subject: |
|
|
Either you make a custom CD which fixes the faulty file(s), or you pick the easy way out, wait 'till the minimum install is done, and emerge -e world when you're done (with the new CFLAGS, of course) |
|
Back to top |
|
|
dete n00b
Joined: 07 Dec 2004 Posts: 10
|
Posted: Tue Dec 07, 2004 8:49 pm Post subject: |
|
|
I thought about emerge -e world, but isn't that going to run into exactly the same problem? The main system (which is calling the config programs) is going to be incompatible.
About building the CD: Are there docs somewhere on how to build my own?
It occurred to me that I'm for all intents and purposes doing a cross-compile; generating code that doesn't work on the host that's doing the building. Is there any Gentoo support for this more general case? |
|
Back to top |
|
|
Eduard Munteanu n00b
Joined: 06 Sep 2006 Posts: 20 Location: Bucuresti, Romania
|
Posted: Fri Sep 22, 2006 3:58 pm Post subject: |
|
|
It's almost 2007 and this problem is still here. Where am I supposed to get a regparm-built glibc to bootstrap the toolchain? This is a chicken and egg problem AFAICS. Any ideas? |
|
Back to top |
|
|
nixnut Bodhisattva
Joined: 09 Apr 2004 Posts: 10974 Location: the dutch mountains
|
Posted: Fri Sep 22, 2006 4:47 pm Post subject: |
|
|
Moved from Installing Gentoo to Unsupported Software.
DIY-cd's are not supported installation methods, so moved here. _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
Back to top |
|
|
irondog l33t
Joined: 07 Jul 2003 Posts: 715 Location: Voor mijn TV. Achter mijn pc.
|
Posted: Fri Sep 22, 2006 8:32 pm Post subject: |
|
|
Eduard Munteanu wrote: | It's almost 2007 and this problem is still here. Where am I supposed to get a regparm-built glibc to bootstrap the toolchain? This is a chicken and egg problem AFAICS. Any ideas? |
Do you think a regparm=3-built-glibc is enough? You'll need a complete stage1 tarball (or similar) built with this flag. Because every app will use glibc and glibc expects every app to pass integer values through registers instead of through the stack.
Gentoo does not support this and that's why you are in this forum right now. Guess what, Gentoo's Glibc ebuilds don't allow you to controll the CFLAGS to be used to build Glibc. So, what you will actually need is not only your own stage tarballs, but also your own customised ebuilds to allow glibc to be built with non-default flags. Of course you must live with the fact that binary packages, like Flash, Skype, Java, etc won't work anymore on your -mregparm=3 system. I'm afaid that packages with a broken buildsystem will choke as well. Hence a package that fails to adopt the CFLAGS in make.conf, such a package will break.
Is that worth all the effort for having a 1% faster computer?
B.T.W. You don't need to build your own liveCD. You'll execute the chroot program which executes /bin/bash built with mregparm=3, but that's not any different from execve()-ing any other binary. _________________ Alle dingen moeten onzin zijn. |
|
Back to top |
|
|
Eduard Munteanu n00b
Joined: 06 Sep 2006 Posts: 20 Location: Bucuresti, Romania
|
Posted: Fri Sep 22, 2006 11:56 pm Post subject: |
|
|
irondog wrote: | Do you think a regparm=3-built-glibc is enough? You'll need a complete stage1 tarball (or similar) built with this flag. Because every app will use glibc and glibc expects every app to pass integer values through registers instead of through the stack. |
irondog, I did not say that. What I need is a mregparm=3-built-glibc to build a mregparm=3-glibc. Compiling glibc's own code isn't the problem, but the configure script. It compiles test code with mregparm=3, but links it against a non-mregparm=3 glibc.
AFAICS, the only way to work around this situation is to fool configure. Since this problem isn't going to get any support, this means a custom ebuild is needed.
I don't see why this needs more than just a special glibc. AFAIK, glibc itself does not require any other libraries to be built and gcc's own ABI does not influence the resulting binaries.
irondog wrote: | Guess what, Gentoo's Glibc ebuilds don't allow you to controll the CFLAGS to be used to build Glibc. |
Hey, but they did allow me! Otherwise we wouldn't have experienced this problem, since -mregparm=3 would've been filtered out.
irondog wrote: | Of course you must live with the fact that binary packages, like Flash, Skype, Java, etc won't work anymore on your -mregparm=3 system. |
I'm aware of this issue, but mregparm=3 might come in handy on some systems (like (most) servers). Anyway, I don't want to discuss the usefulness of this flag (in fact, I chose not to use it on my desktop). |
|
Back to top |
|
|
Enlight Advocate
Joined: 28 Oct 2004 Posts: 3519 Location: Alsace (France)
|
Posted: Sat Sep 23, 2006 2:49 am Post subject: |
|
|
Well this question doesn't interess me as much 'cause I'm now on amd64 (and when I run 32 bits apps, it's only for binary compability), but you need to understand that modifying ABI requires the same actions as cross-compiling, so you have to built a static toolchain, then start with glibc (IMHO)... unfortunately, I never figured out how to build a static toolchain with gentoo... Maybe I didn't looked deep enough into the toolchain eclass.
Still if you plan on modifying as far you system, go for malign-double and all flags that changes the abi in the x86_64 way, try also freg-struct-registers etc...
edit : about cflags control, souldn't add the abi cflags to ALLOWED_FLAGS be enough? |
|
Back to top |
|
|
irondog l33t
Joined: 07 Jul 2003 Posts: 715 Location: Voor mijn TV. Achter mijn pc.
|
Posted: Sat Sep 23, 2006 10:45 am Post subject: |
|
|
Eduard Munteanu wrote: | irondog, I did not say that. What I need is a mregparm=3-built-glibc to build a mregparm=3-glibc. | Forget about it, please. You can build an mregparm=3 glibc with for example crosstool, but such a build will be terrably broken.
I forgot to mention: Glibc contains much hand-written ASM code which is mregparm=3 incompatible. So building it with mregparm=3 in CFLAGS is not enough, Glibc's source needs to be hacked for this to work.
Eduard Munteanu wrote: | AFAICS, the only way to work around this situation is to fool configure. | You don't need to fool configure. As long as configure thinks that a cross-compiler will be used, all checks that fail for you, stop failing.
Forget about it, ok? _________________ Alle dingen moeten onzin zijn. |
|
Back to top |
|
|
Eduard Munteanu n00b
Joined: 06 Sep 2006 Posts: 20 Location: Bucuresti, Romania
|
Posted: Sat Sep 23, 2006 1:56 pm Post subject: |
|
|
I understand. Thanks for pointing out the cross-compiler could work. I had just a theoretical interest in this matter (thought it could help in certain environments to have mregparm).
Yes, glibc contains inline asm, but I think it's only related to syscalls and such (correct me if I'm wrong, please). And userspace <-> kernelspace ABI is not affected by something like mregparm=3, there is a standard interface no matter how you build apps/kernel (probably that's why we have hardcoded asm here and there).
Anyway, I personally don't recommend this flag unless the risks/benefits balance strongly favors it (which doesn't happen usually), so we're on the same side. |
|
Back to top |
|
|
irondog l33t
Joined: 07 Jul 2003 Posts: 715 Location: Voor mijn TV. Achter mijn pc.
|
Posted: Sat Sep 23, 2006 4:48 pm Post subject: |
|
|
Eduard Munteanu wrote: | I understand. Thanks for pointing out the cross-compiler could work. I had just a theoretical interest in this matter (thought it could help in certain environments to have mregparm). | Oh yes, certainly. But it won't be worth the effort I think, because much things will break.
Quote: | Yes, glibc contains inline asm, but I think it's only related to syscalls and such (correct me if I'm wrong, please). | I think not, but I'm not a Glibc hacker or expert.
Quote: | And userspace <-> kernelspace ABI is not affected by something like mregparm=3, there is a standard interface no matter how you build apps/kernel (probably that's why we have hardcoded asm here and there). | It doesn't affect the userspace <-> kernel api. But as soon as you are inlining assembly, things can break horribly when arguments are in the wrong place. I'm afaid this will happen.
Quote: | Anyway, I personally don't recommend this flag unless the risks/benefits balance strongly favors it (which doesn't happen usually), so we're on the same side. | So do I think.
I'll try to build and run programs against an mregparm=3 glibc if I'll find some time. Just for fun. _________________ Alle dingen moeten onzin zijn. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|