gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

Hi Dear Gcc developers,

When I am trying to build Mozilla with gcc-mingw, I came across
the linkage error of undefined symbols in multiple inheritance case.
And I have made a simple test case to reproduce the problem. But the
test case is still very complex, I think. So, I came down to find the
what are the real problems. And now, I think I have, so I just
describe what I found here:

For a class hierarchy :

class SuperSuperBase {
public:
SuperSuperBase();
~SuperSuperBase();

virtual void __attribute__((__stdcall__)) funcSSB() = 0;
};

class SuperBase : public SuperSuperBase {
public:
SuperBase();
~SuperBase();

virtual void __attribute__((__stdcall__)) funcSB() = 0;
};

class Base : public SuperBase {
public:
Base();
~Base();

virtual void __attribute__((__stdcall__)) funcB() = 0;
};

class ChildA: public Base {
public:
ChildA();
~ChildA();

virtual void __attribute__((__stdcall__)) funcCA() = 0;
};

class ChildB: public SuperBase {
public:
ChildB();
~ChildB();

virtual void __attribute__((__stdcall__)) funcCB() = 0;
};

class DLL Child :   public  ChildA,
 public  ChildB {
public:
Child();
~Child();

virtual void __attribute__((__stdcall__)) funcSSB();
virtual void __attribute__((__stdcall__)) funcSB();
virtual void __attribute__((__stdcall__)) funcB();
virtual void __attribute__((__stdcall__)) funcCB();
virtual void __attribute__((__stdcall__)) funcCA();
};

I make the Child in a DLL and then I import it from the DLL to build a
test application. But I failed with the undefined symbols of
"funcSSB,funcSB,funcCB".
And the errors occurs when I build with gcc 4.3.0 but not with gcc
3.4.2. So, I use i686-mingw32-nm to dump the object file which
contains the definition of the Child class. And for the three
undefined functions, the two compiler output different symbols,
Gcc 3.4.2:
 U __ZTVN10__cxxabiv117__class_type_infoE
 U __ZTVN10__cxxabiv120__si_class_type_infoE
 U __ZTVN10__cxxabiv121__vmi_class_type_infoE
 T [EMAIL PROTECTED]
 T [EMAIL PROTECTED]
 T [EMAIL PROTECTED]

Gcc 4.3.0:
 U __ZTVN10__cxxabiv117__class_type_infoE
 U __ZTVN10__cxxabiv120__si_class_type_infoE
 U __ZTVN10__cxxabiv121__vmi_class_type_infoE
0306 T __ZThn4_N5Child6funcCBEv
 U [EMAIL PROTECTED]
02d7 T __ZThn4_N5Child6funcSBEv
 U [EMAIL PROTECTED]
02c8 T __ZThn4_N5Child7funcSSBEv
 U [EMAIL PROTECTED]

I think the difference here is the key point of the linkage error.
Could anybody help to give some more insight here? Any advice will be
appreciated very much!

Regards!
Bo

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

>When I am trying to build Mozilla with gcc-mingw, I came across
> the linkage error of undefined symbols in multiple inheritance case.
> And I have made a simple test case to reproduce the problem. But the
> test case is still very complex, I think. So, I came down to find the
> what are the real problems. And now, I think I have, so I just
> describe what I found here:
>
> For a class hierarchy :
>
> class SuperSuperBase {
> public:
>SuperSuperBase();
>~SuperSuperBase();
>
>virtual void __attribute__((__stdcall__)) funcSSB() = 0;
> };
>
> class SuperBase : public SuperSuperBase {
> public:
>SuperBase();
>~SuperBase();
>
>virtual void __attribute__((__stdcall__)) funcSB() = 0;
> };
>
> class Base : public SuperBase {
> public:
>Base();
>~Base();
>
>virtual void __attribute__((__stdcall__)) funcB() = 0;
> };
>
> class ChildA: public Base {
> public:
>ChildA();
>~ChildA();
>
>virtual void __attribute__((__stdcall__)) funcCA() = 0;
> };
>
> class ChildB: public SuperBase {
> public:
>ChildB();
>~ChildB();
>
>virtual void __attribute__((__stdcall__)) funcCB() = 0;
> };
>
> class DLL Child :   public  ChildA,
> public  ChildB {
> public:
>Child();
>~Child();
>
>virtual void __attribute__((__stdcall__)) funcSSB();
>virtual void __attribute__((__stdcall__)) funcSB();
>virtual void __attribute__((__stdcall__)) funcB();
>virtual void __attribute__((__stdcall__)) funcCB();
>virtual void __attribute__((__stdcall__)) funcCA();
> };
>
> I make the Child in a DLL and then I import it from the DLL to build a
> test application. But I failed with the undefined symbols of
> "funcSSB,funcSB,funcCB".
> And the errors occurs when I build with gcc 4.3.0 but not with gcc
> 3.4.2. So, I use i686-mingw32-nm to dump the object file which
> contains the definition of the Child class. And for the three
> undefined functions, the two compiler output different symbols,
> Gcc 3.4.2:
> U __ZTVN10__cxxabiv117__class_type_infoE
> U __ZTVN10__cxxabiv120__si_class_type_infoE
> U __ZTVN10__cxxabiv121__vmi_class_type_infoE
>  T [EMAIL PROTECTED]
>  T [EMAIL PROTECTED]
>  T [EMAIL PROTECTED]
>
> Gcc 4.3.0:
> U __ZTVN10__cxxabiv117__class_type_infoE
> U __ZTVN10__cxxabiv120__si_class_type_infoE
> U __ZTVN10__cxxabiv121__vmi_class_type_infoE
> 0306 T __ZThn4_N5Child6funcCBEv
> U [EMAIL PROTECTED]
> 02d7 T __ZThn4_N5Child6funcSBEv
> U [EMAIL PROTECTED]
> 02c8 T __ZThn4_N5Child7funcSSBEv
> U [EMAIL PROTECTED]
>
> I think the difference here is the key point of the linkage error.
> Could anybody help to give some more insight here? Any advice will be
> appreciated very much!

Could anybody give some advice on this? Thanks!

Regards!
Bo

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

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 ?  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
0007 T __ZThn4_N6bottom4fun1Ev
 U [EMAIL PROTECTED]
0021 T __ZThn4_N6bottom4fun2Ev
 U [EMAIL PROTECTED]
003b T __ZThn4_N6bottom4fun3Ev
 U [EMAIL PROTECTED]
 T __ZThn4_N6bottom4fun5Ev
 U [EMAIL PROTECTED]
 T __ZThn4_N6bottomD0Ev
 T __ZThn4_N6bottomD1Ev
 T __ZThn8_N6bottom4fun1Ev
 U [EMAIL PROTECTED]
001a T __ZThn8_N6bottom4fun2Ev
 U [EMAIL PROTECTED]
0034 T __ZThn8_N6bottom4fun3Ev
 U [EMAIL PROTECTED]
 T __ZThn8_N6bottom4fun6Ev
 U [EMAIL PROTECTED]
 T __ZThn8_N6bottomD0Ev
 T __ZThn8_N6bottomD1Ev

Take the
0007 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

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Bo Yang wrote:
>
>> 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
>
> That's not how it works, the linker is always required to produce an
> executable.

I am wrong. But how the linker find the __attribute__((__stdcall__))
bottom::fun1() when there is a single source file? There is no such
definition in the object file.

>> 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()" .
>
> The "U" lines are correct and aren't the problem; those are call sites
> to the properly mangled symbol name.  What's incorrect is that gcc emits
> the function definitions (the 'T' lines) without the proper stdcall name
> mangling.  If gcc used the proper mangling for the definitions then the
> undefined call sites would no longer be undefined and would not show up
> in the objdump output any more.

So, are you sure this bug is identical to PR27067 or not?

Regards!
Bo