This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tru64 non-virtual thunks multiply defined
- From: "Peter O'Gorman" <pogma at thewrittenword dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 6 Jan 2009 09:12:05 -0600
- Subject: Re: Tru64 non-virtual thunks multiply defined
- References: <20081219173222.GA18155@localhost.localdomain> <20081230014324.GH18155@localhost.localdomain> <4962BEAB.1040603@codesourcery.com>
Hi Nathan,
Thanks for replying. I did not manage to get gcc trunk built on the
Tru64 machine to confirm that it is still a problem (out of memory in
stage2 compiling fold-const.c, but that's a whole different issue).
On Mon, Jan 05, 2009 at 06:15:07PM -0800, Nathan Sidwell wrote:
> Peter O'Gorman wrote:
> > Is this patch itself to blame, or does it simply expose a latent bug?
>
> It is exposing a latent bug. There was a bug where multiple logically-distinct
> thunks were emitted even though they all had the same effect, and hence the same
> names.
>
I think I failed to be clear enough. Before this patch, thunks
pointing to weak functions on Tru64 were weak, after it, the functions
remain weak, but the thunks are not. This is problematic.
For example, after compiling the attachment to PR38581:
% nm -Bw f.o | grep N3MI1D0 | c++filt
0x00000000000000 N $_ZN3MI1D0Ev..ng
0x00000000000000 N $_ZThn8_N3MI1D0Ev..ng
0x00000000000000 N $_ZTv0_n32_N3MI1D0Ev..ng
0x00000000000af8 T* MI1::~MI1()
0x00000000000ae4 T non-virtual thunk to MI1::~MI1()
0x00000000000ac8 T virtual thunk to MI1::~MI1()
Since the destructor is weak (the * indicates weak), the thunks should
also be, and when we revert your fix, they are, indeed, all weak.
We don't have this problem with the same compiler version on AIX, HP-UX,
IRIX, Linux or Solaris, and since you say that it's a latent bug, it
does seems likely to be some issue with just the Tru64/alpha target.
> > Will reverting this patch in the gcc that we ship cause any real
> > problems?
>
> Yes, it may cause the thunks to be placed far from the thunked-to function and
> hence have jump range problems. Perhaps that's not an issue on Tru64 though
Ok, depends on exactly how far away, I guess :). We haven't run into it,
so we can cross our fingers and hope. Until we can find the real bug
though it seems better for us to have a working compiler than a
semi-working one :/.
Probably best to leave further discussion to the bug report now.
Thank you,
Peter
--
Peter O'Gorman
pogma@thewrittenword.com