upgrading to 7.0.3 causes assembly errors
So I just upgraded to 7, and on compiling I got: /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0: suffix or operands invalid for `push' /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0: suffix or operands invalid for `push' ... etc. Some digging revealed that it was actually in the compilation of a *_stub.c file, and the underlying problem is thus: This is OS X 10.6. For various reasons, my app is compiled 32 bit, and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc. Previously, of course, this wasn't necessary since ghc always produced 32 bit code. But now there seems to be an issue with flag order. When ghc wants to compile the stub, it runs: g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of my flags Then it wants to assemble it: /Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o ./Ui/RulerC_stub.o -m64 -fno-stack-protector So it looks like when compiling, the user flags go last, overriding the new default -m64. But when assembling, they go first, and are overidden. This seems like an easy fix, I imagine it's just constructing the cmdline inconsistently. Is there a way for me to influence how it constructs the cmdline for gcc for stubs? I mean, without recompiling ghc. I'm supposed to be able to get ghc to compile 32 bit, right? It also seems odd to me that it's compiled and assembled separately, but I suppose there must have been some reason for that. I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...
On 04/05/2011 22:38, Evan Laforge wrote:
So I just upgraded to 7, and on compiling I got:
/var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0: suffix or operands invalid for `push'
/var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0: suffix or operands invalid for `push'
... etc.
Some digging revealed that it was actually in the compilation of a *_stub.c file, and the underlying problem is thus:
This is OS X 10.6. For various reasons, my app is compiled 32 bit, and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc. Previously, of course, this wasn't necessary since ghc always produced 32 bit code. But now there seems to be an issue with flag order. When ghc wants to compile the stub, it runs:
g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of my flags
Then it wants to assemble it:
/Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o ./Ui/RulerC_stub.o -m64 -fno-stack-protector
So it looks like when compiling, the user flags go last, overriding the new default -m64. But when assembling, they go first, and are overidden.
This seems like an easy fix, I imagine it's just constructing the cmdline inconsistently. Is there a way for me to influence how it constructs the cmdline for gcc for stubs? I mean, without recompiling ghc. I'm supposed to be able to get ghc to compile 32 bit, right?
No, GHC compiles either for 32-bit or 64-bit, chosen when GHC is built. You probably want to install the 32-bit version of GHC. I'm not sure how this worked for you before... Anyway, it looks like the argument ordering for the assembler has already changed in 7.2, so I think your particular issue should have gone away.
It also seems odd to me that it's compiled and assembled separately, but I suppose there must have been some reason for that.
I don't think there's a very good reason for it, we could probably change it.
I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...
Yes, if you could check with the 7.2.1 release candidate when we put one out, that would be very helpful. Cheers, Simon
No, GHC compiles either for 32-bit or 64-bit, chosen when GHC is built. You probably want to install the 32-bit version of GHC.
Ohh, so ghc always produces one kind, and no amount of -m flags will change that? I see, I thought it was like gcc that just took a flag.
I'm not sure how this worked for you before...
Before ghc on OS X always produced 32bit, but gcc defaulted to 64bit. So I set a bunch of flags so that whenever ghc invoked gcc it would pass a -m32.
Anyway, it looks like the argument ordering for the assembler has already changed in 7.2, so I think your particular issue should have gone away.
But if I'm understanding you correctly, the underlying issue is ghc only being able to produce one "width", so even if the args are consistent ghc will still be producing whatever width it was compiled for.
I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...
Yes, if you could check with the 7.2.1 release candidate when we put one out, that would be very helpful.
Ok, looking forward to it! I followed the directions on the wiki but I'm a git newbie so I don't really understand its branching model. After a clone of ghc.git, do I have the latest 7.2 or is this a stable branch or something? I just want to make sure if I make changes I'm working from the most up to date version.
On 05/05/2011 16:23, Evan Laforge wrote:
No, GHC compiles either for 32-bit or 64-bit, chosen when GHC is built. You probably want to install the 32-bit version of GHC.
Ohh, so ghc always produces one kind, and no amount of -m flags will change that? I see, I thought it was like gcc that just took a flag.
Correct. There are moves afoot to let GHC support -m32/-m64, but it will be a while (probably not 7.2.1).
I'm not sure how this worked for you before...
Before ghc on OS X always produced 32bit, but gcc defaulted to 64bit. So I set a bunch of flags so that whenever ghc invoked gcc it would pass a -m32.
Ok, that was a bug which is fixed in the 7.0 series.
I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...
Yes, if you could check with the 7.2.1 release candidate when we put one out, that would be very helpful.
Ok, looking forward to it! I followed the directions on the wiki but I'm a git newbie so I don't really understand its branching model. After a clone of ghc.git, do I have the latest 7.2 or is this a stable branch or something? I just want to make sure if I make changes I'm working from the most up to date version.
There isn't a branch for 7.2 yet, we plan to create one soon and we'll put the details for checking it out on the wiki. Also, we are still building snapshot binary distributions as usual, so you don't have to build GHC yourself. Cheers, Simon
participants (2)
-
Evan Laforge -
Simon Marlow