On Thu, Jul 31, 2008 at 12:48 AM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Benjamin Smedberg wrote:
>
>> For what it's worth, Bo is my intern in the Google SoC and has traced this
>> back to being a code-generation error (missed stdcall mangling) in the mingw
>> backend. I will work with him to narrow the problem and reformulate the
>> question..
>
> Isn't this <http://gcc.gnu.org/PR27067>?  If so it has regressed as that
> was supposedly fixed in 4.3.

I have test the PR27067's test case, and it indeed works. I mean, gcc
4.3.0 create a correct app. But in Mozilla, the problem is not such
simple. The test case is just to compile a single c++ source file to
get a exe. There is no shared library and import library.
After I compile the test case of PR27067, I examine the object file of
the c++ file and I got:

         U __ZTVN10__cxxabiv117__class_type_infoE
         U __ZTVN10__cxxabiv120__si_class_type_infoE
         U __ZTVN10__cxxabiv121__vmi_class_type_infoE
00000007 T __ZThn4_N6bottom4fun1Ev
         U [EMAIL PROTECTED]
00000021 T __ZThn4_N6bottom4fun2Ev
         U [EMAIL PROTECTED]
0000003b T __ZThn4_N6bottom4fun3Ev
         U [EMAIL PROTECTED]
00000000 T __ZThn4_N6bottom4fun5Ev
         U [EMAIL PROTECTED]
00000000 T __ZThn4_N6bottomD0Ev
00000000 T __ZThn4_N6bottomD1Ev
00000000 T __ZThn8_N6bottom4fun1Ev
         U [EMAIL PROTECTED]
0000001a T __ZThn8_N6bottom4fun2Ev
         U [EMAIL PROTECTED]
00000034 T __ZThn8_N6bottom4fun3Ev
         U [EMAIL PROTECTED]
00000000 T __ZThn8_N6bottom4fun6Ev
         U [EMAIL PROTECTED]
00000000 T __ZThn8_N6bottomD0Ev
00000000 T __ZThn8_N6bottomD1Ev

Take the
00000007 T __ZThn4_N6bottom4fun1Ev
               U [EMAIL PROTECTED]
for example. Very similar pattern, yes, it is the same pattern with my
test case above. And this this mean that our object file has the
definition of  bottom:fun1() but not have the definition of
__attribute__((__stdcall__)) bottom:fun1().
Obviously, we have definition of __attribute__((__stdcall__))
bottom:fun1(), but the generated object file said it does not have!

When we produce an exe from a single c++ file, there is no linking
need, so there is no problem. But when we separate the definition and
the usage. I mean, we put the definition into a DLL and then use it to
generate another exe. This time, we need a linker to link the DLL.
Rationally, the linker should search for [EMAIL PROTECTED]
(__attribute__((__stdcall__)) bottom:fun1() ), but it only find there
is a "  U [EMAIL PROTECTED]" in the library, so a fail occur
this way.
And Obviously, this is not a linker error, it is the problem gcc
generate a " U [EMAIL PROTECTED]" for indeed existing
definition of "__attribute__((__stdcall__)) bottom:fun1()" .

I hope I make the problem clear here. Any question and advice are welcomed!

Regards!
Bo

Reply via email to