Re: MinGW x86_64 ABI problem

Re: MinGW x86_64 ABI problem

[Joern Rennecke]

> 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.

Re: MinGW x86_64 ABI problem

[John Fine]

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.

Re: MinGW x86_64 ABI problem

[Joern Rennecke]

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.

friendly operator overloading

[Bernd Prager]

Hi,

I need some help with operator overloading.
Following test program compiles and runs fine with g++ (GCC) 4.1.2:

#include <iostream>
#include <string>

namespace xxx
{
class Container
{
friend std::ostream &operator<<(std::ostream&, const Container&);
private:
    int id;
    std::string s;
public:
    Container() : s("Hello World") {}
};


std::ostream &operator<<(std::ostream &stream, const Container &c)
{
    return std::cout << c.s << std::endl;
}
} // namespace

using namespace xxx;
int main()
{
    Container* c = new Container();

    std::cout << *c;

    return 0;
}

As long as I use it one (!) source file.

When I separate the Container class in separate Container.h and a
Container.cpp files the compiler complains about:
$ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
-o tst
container.h: In function ‘std::ostream& operator<<(std::ostream&, const
xxx::Container&)’:
container.h:13: error: ‘std::string xxx::Container::s’ is private
container.cpp:8: error: within this context
make: *** [tst] Error 1

When I was trying to find out what is going on, I just put s into public.
Then I get the error message:

$ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
-o tst
/tmp/ccCAgEWK.o: In function `main':
tst.cpp:(.text+0xb3): undefined reference to
`xxx::operator<<(std::basic_ostream<char, std::char_traits<char> >&,
xxx::Container const&)'
collect2: ld returned 1 exit status
make: *** [tst] Error 1

What makes me believe that there is some trouble with the namespace of the
operator<< definition, but only if I use separate files.

Anybody has any suggestion?

Thank you very much for any help,
-- Bernd

Re: friendly operator overloading

[Axel Freyn]

Hi Bernd,

for me (g++ 4.2.1) it runs in both situations.
On Mon, Feb 23, 2009 at 08:09:22AM -0700, Bernd Prager wrote:
> #include <iostream>
> #include <string>
> namespace xxx
> {
> class Container
> {
> friend std::ostream &operator<<(std::ostream&, const Container&);
> private:
>     int id;
>     std::string s;
> public:
>     Container() : s("Hello World") {}
> };
> std::ostream &operator<<(std::ostream &stream, const Container &c)
> {
>     return std::cout << c.s << std::endl;
> }
> } // namespace
> using namespace xxx;
> int main()
> {
>     Container* c = new Container();
>     std::cout << *c;
>     return 0;
> }
> 
> As long as I use it one (!) source file.
> 
> When I separate the Container class in separate Container.h and a
> Container.cpp files the compiler complains about:
> $ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
> -o tst
> container.h: In function ‘std::ostream& operator<<(std::ostream&, const
> xxx::Container&)’:
> container.h:13: error: ‘std::string xxx::Container::s’ is private
> container.cpp:8: error: within this context
> make: *** [tst] Error 1
I suspect this is a problem how you defined operator <<. It works with
the following files ( operator << is defined OUTSIDE namespace xxx, and
before it is used in class Container):


container.h:

namespace xxx{
  class Container;
}
std::ostream &operator<<(std::ostream&, const xxx::Container&);
namespace xxx
{
class Container
{
friend std::ostream &::operator<<(std::ostream&, const xxx::Container&);
private:
    int id;
    std::string s;
public:
    Container();
};
}


container.cpp:

#include "container.h"
namespace xxx
{
Container::Container() : s("Hello World") {}
}
std::ostream &operator<<(std::ostream &stream, const xxx::Container &c)
{
    return std::cout << c.s << std::endl;
}


test.cpp:

#include "container.h"
using namespace xxx;
int main()
{
    Container* c = new Container();
    std::cout << *c;
    return 0;
}


Of course, it is also possible to define operator << inside the
namespace. 

HTH - if not, it would be useful if you could send the three seperated
files you used,

Axel

MinGW x86_64 ABI problem

[John Fine]

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?

Re: MinGW x86_64 ABI problem

[NightStrike]

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?

Re: MinGW x86_64 ABI problem

[John Fine]

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?
>
>   

Re: MinGW x86_64 ABI problem

[NightStrike]

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!