This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc emit wrong symbols in multiple inheritance case
- From: "Bo Yang" <techrazy dot yang at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Cc: brian at dessent dot net, "Benjamin Smedberg" <bsmedberg at mozilla dot com>, "Ian Lance Taylor" <iant at google dot com>
- Date: Fri, 1 Aug 2008 11:24:10 +0800
- Subject: Re: gcc emit wrong symbols in multiple inheritance case
- References: <a47d5c0807252033m51f8a3b9sbf1a390a22c19546@mail.gmail.com> <a47d5c0807281831v27c4c7aaw50d0d68112e6eb5@mail.gmail.com> <m3k5f54btl.fsf@google.com> <48909947.6020600@mozilla.com> <48909B70.F6D8D79D@dessent.net> <a47d5c0807310358jb02cc59tc5184c872d8582c4@mail.gmail.com> <4891D384.8A06BCCA@dessent.net>
On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent <brian@dessent.net> 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 __ZThn4_N6bottom4fun1Ev@4" 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