* Re: MinGW x86_64 ABI problem
@ 2009-02-24 12:45 Joern Rennecke
2009-02-24 13:30 ` John Fine
0 siblings, 1 reply; 7+ messages in thread
From: Joern Rennecke @ 2009-02-24 12:45 UTC (permalink / raw)
To: John Fine; +Cc: gcc-help
> 1) Can you tell me where callee saved registers are specified in the gcc source code.
To a first order of approximation, that's the CALL_USED_REGS macro in
tm.h (config/i386/i386.h).
But it can get refined in other places, as in this case in
CONDITIONAL_REGISTER_USAGE. Some ports also use OVERRIDE_OPTIONS,
for mainly historical reasons.
> 2) I tried adding "-f-call-saved-xmm9" to the g++ command to see if that would fix the problem for one register. That compile aborted with
> internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1590
> Is that switch so incorrect? I understand it would generate .obj code incompatible with anything generated without that switch. But why should it crash gcc?
Different registers need to be copied in different ways. If a port does
not anticipate that a certain register class may need saving, the generic
code to implement saving of registers across calls can emit instructions
that can not be recognized, so that code like:
extract_insn (insn);
if (! constrain_operands (1))
fatal_insn_not_found (insn);
will abort.
You'd have to fix the machine description to recognize and implement properly
these register saves and restores. And then you'll have to recompile
all the libraries with your changed ABI.
If you only have a few entry points in your DLL, it might be simpler
to write some wrapper code in assembler to save and restore the xmm
registers.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MinGW x86_64 ABI problem
2009-02-24 12:45 MinGW x86_64 ABI problem Joern Rennecke
@ 2009-02-24 13:30 ` John Fine
2009-02-24 14:00 ` Joern Rennecke
0 siblings, 1 reply; 7+ messages in thread
From: John Fine @ 2009-02-24 13:30 UTC (permalink / raw)
To: gcc-help; +Cc: Joern Rennecke
Joern Rennecke wrote:
> To a first order of approximation, that's the CALL_USED_REGS macro in
> tm.h (config/i386/i386.h).
>
Thankyou.
> If a port does
> not anticipate that a certain register class may need saving, the generic
> code to implement saving of registers across calls can emit instructions
> that can not be recognized,
I figured that out after sending the first email. But I don't know what
to do about it.
There is no instruction to push or pop an xmm register. The code seems
to expect to be able to push and pop.
If I knew more about gcc internals, I could invent a multi instruction
sequence to push or pop, but the result would be very inefficient
(because several xmm registers need to be saved and restored in the
typical function).
There are architectures that don't have push/pop at all as well as some
where push/pop are slower than the alternative. In many compilers (I
assume gcc, but haven't checked) the prolog code can sub the right
amount from rsp for both local variables and saving
callee-saved-registers, then move those registers into the right place
in the stack frame.
What/where do I change in gcc to tell it that is the way to save and
restore xmm registers.
> You'd have to fix the machine description to recognize and implement properly
> these register saves and restores. And then you'll have to recompile
> all the libraries with your changed ABI.
>
I expected I might need to do that. I'm trying to find out how.
> If you only have a few entry points in your DLL, it might be simpler
> to write some wrapper code in assembler to save and restore the xmm
> registers.
>
I have considered that. But it is quite a bit trickier than that
description implies. The DLL is actually built on the fly while the
main application is running. I don't have a decent way to know which
entry points even use xmm registers. It would be quite ugly to save ten
128 bit registers on every entry point when only a few of those entry
points even use them.
Any idea why I don't see this issue discussed on the net, and why
someone else hasn't fixed it already? Or have they and I just haven't
looked in the right place?
Doesn't anyone else try to create .lib or .dll files with MinGW that can
be called from standard win64 .exe's?
As soon as the called function has a few float or double local
variables, plus any function up the call stack in the exe also has a few
float or double local variables, the result should malfunction. I can't
believe I'm the only one seeing this.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MinGW x86_64 ABI problem
2009-02-24 13:30 ` John Fine
@ 2009-02-24 14:00 ` Joern Rennecke
0 siblings, 0 replies; 7+ messages in thread
From: Joern Rennecke @ 2009-02-24 14:00 UTC (permalink / raw)
To: John Fine; +Cc: gcc-help
On Tue, Feb 24, 2009 at 08:29:32AM -0500, John Fine wrote:
> There is no instruction to push or pop an xmm register. The code seems
> to expect to be able to push and pop.
>
> If I knew more about gcc internals, I could invent a multi instruction
> sequence to push or pop, but the result would be very inefficient
> (because several xmm registers need to be saved and restored in the
> typical function).
It should be relatively easy to peephole multiple such patterns into
a single one.
> There are architectures that don't have push/pop at all as well as some
> where push/pop are slower than the alternative. In many compilers (I
> assume gcc, but haven't checked) the prolog code can sub the right
> amount from rsp for both local variables and saving
> callee-saved-registers, then move those registers into the right place
> in the stack frame.
Look for ACCUMULATE_OUTGOING_ARGS.
> What/where do I change in gcc to tell it that is the way to save and
> restore xmm registers.
Gcc either wants to push all register classes or use standard stores
for all.
> Any idea why I don't see this issue discussed on the net, and why
> someone else hasn't fixed it already? Or have they and I just haven't
> looked in the right place?
Either you are looking not hard enough, or noone else has posted about
it yet.
> Doesn't anyone else try to create .lib or .dll files with MinGW that can
> be called from standard win64 .exe's?
I don't know. It's been some years since I last looked at MingW.
> As soon as the called function has a few float or double local
> variables, plus any function up the call stack in the exe also has a few
> float or double local variables, the result should malfunction. I can't
> believe I'm the only one seeing this.
Let's not forget the other preconditions: 64 bit computing,
MingW, and mixing GNU tools with another toolchain.
Each not that uncommon, but the intersection of all these may be small.
And someone has to be the first one to see anything that is to be seen.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MinGW x86_64 ABI problem
2009-02-24 17:35 ` John Fine
@ 2009-02-24 18:26 ` NightStrike
0 siblings, 0 replies; 7+ messages in thread
From: NightStrike @ 2009-02-24 18:26 UTC (permalink / raw)
To: John Fine; +Cc: Kai Tietz, gcc-help, mingw-w64-public
On Tue, Feb 24, 2009 at 12:35 PM, John Fine <johnsfine@verizon.net> wrote:
> Thankyou. Problem solved. Apologies for my misunderstanding of version
> status.
>
> I didn't realize there were newer versions than what I had. I was just
> looking at the "4.4.0". I couldn't find any mention of the bug on the
> website, so I didn't think it was likely that it had been fixed recently.
> Reinstalling a newer build was one of the items on my todo list for chasing
> this problem, but since I saw no mention of the bug fix, it wasn't high
> enough on that list.
>
> I thought I was using a newer build of 4.4.0 than I actually was (not sure
> what I did wrong when getting that) but I just now double checked and it was
> 4.4.0 20080528 (experimental)
>
> I just reinstalled from with "4.4.0 20090221" and confirmed that the bug was
> fixed.
Good news!
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MinGW x86_64 ABI problem
2009-02-24 17:00 ` NightStrike
@ 2009-02-24 17:35 ` John Fine
2009-02-24 18:26 ` NightStrike
0 siblings, 1 reply; 7+ messages in thread
From: John Fine @ 2009-02-24 17:35 UTC (permalink / raw)
To: NightStrike; +Cc: Kai Tietz, gcc-help, mingw-w64-public
Thankyou. Problem solved. Apologies for my misunderstanding of version
status.
I didn't realize there were newer versions than what I had. I was just
looking at the "4.4.0". I couldn't find any mention of the bug on the
website, so I didn't think it was likely that it had been fixed
recently. Reinstalling a newer build was one of the items on my todo
list for chasing this problem, but since I saw no mention of the bug
fix, it wasn't high enough on that list.
I thought I was using a newer build of 4.4.0 than I actually was (not
sure what I did wrong when getting that) but I just now double checked
and it was
4.4.0 20080528 (experimental)
I just reinstalled from with "4.4.0 20090221" and confirmed that the bug
was fixed.
NightStrike wrote:
>
> First, I added both the mingw-w64 mailing list to the chain as well as
> Kai Tietz.
>
> Second, what version of the toolchain are you using? Is it from our
> site? Is it after Jan 19th of 2009?
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: MinGW x86_64 ABI problem
2009-02-23 22:33 ` MinGW x86_64 ABI problem John Fine
@ 2009-02-24 17:00 ` NightStrike
2009-02-24 17:35 ` John Fine
0 siblings, 1 reply; 7+ messages in thread
From: NightStrike @ 2009-02-24 17:00 UTC (permalink / raw)
To: John Fine, Kai Tietz; +Cc: gcc-help, mingw-w64-public
On Mon, Feb 23, 2009 at 5:33 PM, John Fine <johnsfine@verizon.net> wrote:
>
> The Windows version of the x86_64 ABI specifies that registers xmm6-xmm15 be callee saved.
>
> I'm building a .dll with MinGW used by an .exe from a different compiler.
>
> I debugged a failure to the point of determining that the code produced by MinGW clobbers xmm9 in violation of the ABI.
>
> I tried a bunch of Google searches, expecting this problem would be discussed somewhere, but couldn't find it.
>
> I'm using a downloaded binary copy of MinGW for x86_64. I expect I will need to download source code and figure out how to build it, in order to deal with this problem.
>
> But I don't know where to look in the gcc source code included in MinGW for the registers that should be callee saved.
>
> 1) Can you tell me where callee saved registers are specified in the gcc source code.
>
> 2) I tried adding "-f-call-saved-xmm9" to the g++ command to see if that would fix the problem for one register. That compile aborted with
> internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1590
> Is that switch so incorrect? I understand it would generate .obj code incompatible with anything generated without that switch. But why should it crash gcc?
>
First, I added both the mingw-w64 mailing list to the chain as well as
Kai Tietz.
Second, what version of the toolchain are you using? Is it from our
site? Is it after Jan 19th of 2009?
^ permalink raw reply [flat|nested] 7+ messages in thread
* MinGW x86_64 ABI problem
2009-02-23 16:14 ` Axel Freyn
@ 2009-02-23 22:33 ` John Fine
2009-02-24 17:00 ` NightStrike
0 siblings, 1 reply; 7+ messages in thread
From: John Fine @ 2009-02-23 22:33 UTC (permalink / raw)
To: gcc-help
The Windows version of the x86_64 ABI specifies that registers
xmm6-xmm15 be callee saved.
I'm building a .dll with MinGW used by an .exe from a different compiler.
I debugged a failure to the point of determining that the code produced
by MinGW clobbers xmm9 in violation of the ABI.
I tried a bunch of Google searches, expecting this problem would be
discussed somewhere, but couldn't find it.
I'm using a downloaded binary copy of MinGW for x86_64. I expect I will
need to download source code and figure out how to build it, in order to
deal with this problem.
But I don't know where to look in the gcc source code included in MinGW
for the registers that should be callee saved.
1) Can you tell me where callee saved registers are specified in the gcc
source code.
2) I tried adding "-f-call-saved-xmm9" to the g++ command to see if that
would fix the problem for one register. That compile aborted with
internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1590
Is that switch so incorrect? I understand it would generate .obj code
incompatible with anything generated without that switch. But why
should it crash gcc?
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-02-24 18:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-24 12:45 MinGW x86_64 ABI problem Joern Rennecke
2009-02-24 13:30 ` John Fine
2009-02-24 14:00 ` Joern Rennecke
-- strict thread matches above, loose matches on Subject: below --
2009-02-23 15:10 friendly operator overloading Bernd Prager
2009-02-23 16:14 ` Axel Freyn
2009-02-23 22:33 ` MinGW x86_64 ABI problem John Fine
2009-02-24 17:00 ` NightStrike
2009-02-24 17:35 ` John Fine
2009-02-24 18:26 ` NightStrike
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).