public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Craig Rodrigues <rodrigc@mediaone.net> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/3947: MIPS multiple inheritance - thunk causes two destructor calls Date: Sun, 27 Jan 2002 17:46:00 -0000 [thread overview] Message-ID: <20020128014606.3180.qmail@sources.redhat.com> (raw) The following reply was made to PR target/3947; it has been noted by GNATS. From: Craig Rodrigues <rodrigc@mediaone.net> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/3947: MIPS multiple inheritance - thunk causes two destructor calls Date: Sun, 27 Jan 2002 20:44:49 -0500 ----- Forwarded message from David Hanney <dh@digitalbrain.com> ----- Delivered-To: rodrigc@gcc.gnu.org X-Sender: dbdave@mail.digitalbrain.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 23 Oct 2001 11:03:54 +0100 To: gcc-gnats@gcc.gnu.org;, gcc-prs@gcc.gnu.org;, rodrigc@gcc.gnu.org;, gcc-bugs@gcc.gnu.org;, nobody@gcc.gnu.org;, simong@oz.agile.tv From: David Hanney <dh@digitalbrain.com> Subject: Fwd: c++/3947 (destructor is called twice) Cc: debian-gcc@lists.debian.org, tim@digitalbrain.com X-Virus-Scanned: by AMaViS perl-11 on this venison of GCC ... >tim@fum:~$ g++-3.0 -v >Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.2/specs >Configured with: ../src/configure -v >--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr >--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as >--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls >--without-included-gettext --disable-checking --enable-threads=posix >--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux >Thread model: posix >gcc version 3.0.2 20010922 (Debian prerelease) >tim@fum:~$ uname -a >Linux fum 2.4.12-VLAN #2 SMP Mon Oct 15 10:20:08 BST 2001 i686 unknown I'm getting a similar problem to http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3947 (and reverting to compiling with 2.95.2 'fixes' it) It makes a thunk that contains an extra destructor. There is no matching constructor. So the destructor is called twice. Here is the function... (no problems here) (see annotations starting with '^') Dump of assembler code for function _ZN9FileStore7SetPathE6String: 0x405ea240 <_ZN9FileStore7SetPathE6String>: push %ebp 0x405ea241 <_ZN9FileStore7SetPathE6String+1>: mov %esp,%ebp 0x405ea243 <_ZN9FileStore7SetPathE6String+3>: push %ebx 0x405ea244 <_ZN9FileStore7SetPathE6String+4>: sub $0x14,%esp 0x405ea247 <_ZN9FileStore7SetPathE6String+7>: sub $0x8,%esp ^ (btw GDB says the function is here) 0x405ea24a <_ZN9FileStore7SetPathE6String+10>: pushl 0xc(%ebp) 0x405ea24d <_ZN9FileStore7SetPathE6String+13>: mov 0x8(%ebp),%eax 0x405ea250 <_ZN9FileStore7SetPathE6String+16>: add $0x4,%eax 0x405ea253 <_ZN9FileStore7SetPathE6String+19>: push %eax 0x405ea254 <_ZN9FileStore7SetPathE6String+20>: call 0x405b0b54 <_ZN6StringaSERKS_> ^ construction (fine!) 0x405ea259 <_ZN9FileStore7SetPathE6String+25>: add $0x10,%esp 0x405ea25c <_ZN9FileStore7SetPathE6String+28>: sub $0x8,%esp 0x405ea25f <_ZN9FileStore7SetPathE6String+31>: pushl 0xc(%ebp) 0x405ea262 <_ZN9FileStore7SetPathE6String+34>: mov 0x8(%ebp),%eax 0x405ea265 <_ZN9FileStore7SetPathE6String+37>: add $0xc,%eax 0x405ea268 <_ZN9FileStore7SetPathE6String+40>: push %eax 0x405ea269 <_ZN9FileStore7SetPathE6String+41>: call 0x405ea734 <_ZN7FileOps7SetPathERK6String> 0x405ea26e <_ZN9FileStore7SetPathE6String+46>: add $0x10,%esp 0x405ea271 <_ZN9FileStore7SetPathE6String+49>: sub $0xc,%esp 0x405ea274 <_ZN9FileStore7SetPathE6String+52>: pushl 0xc(%ebp) 0x405ea277 <_ZN9FileStore7SetPathE6String+55>: call 0x405ae688 <_ZN6StringD1Ev> ^ matching destruction (fine!) 0x405ea27c <_ZN9FileStore7SetPathE6String+60>: add $0x10,%esp 0x405ea27f <_ZN9FileStore7SetPathE6String+63>: jmp 0x405ea2a8 <_ZN9FileStore7SetPathE6String+104> 0x405ea281 <_ZN9FileStore7SetPathE6String+65>: lea 0x0(%esi),%esi 0x405ea284 <_ZN9FileStore7SetPathE6String+68>: mov %eax,0xfffffff8(%ebp) 0x405ea287 <_ZN9FileStore7SetPathE6String+71>: mov 0xfffffff8(%ebp),%ebx 0x405ea28a <_ZN9FileStore7SetPathE6String+74>: sub $0xc,%esp 0x405ea28d <_ZN9FileStore7SetPathE6String+77>: pushl 0xc(%ebp) 0x405ea290 <_ZN9FileStore7SetPathE6String+80>: call 0x405ae688 <_ZN6StringD1Ev> 0x405ea295 <_ZN9FileStore7SetPathE6String+85>: add $0x10,%esp 0x405ea298 <_ZN9FileStore7SetPathE6String+88>: mov %ebx,0xfffffff8(%ebp) 0x405ea29b <_ZN9FileStore7SetPathE6String+91>: sub $0xc,%esp 0x405ea29e <_ZN9FileStore7SetPathE6String+94>: pushl 0xfffffff8(%ebp) 0x405ea2a1 <_ZN9FileStore7SetPathE6String+97>: call 0x4093f400 0x405ea2a6 <_ZN9FileStore7SetPathE6String+102>: mov %esi,%esi 0x405ea2a8 <_ZN9FileStore7SetPathE6String+104>: mov 0xfffffffc(%ebp),%ebx 0x405ea2ab <_ZN9FileStore7SetPathE6String+107>: leave 0x405ea2ac <_ZN9FileStore7SetPathE6String+108>: ret Here is the bogus thunk ... (see annotations starting with '^') Dump of assembler code for function _ZTv0_n28_N9FileStore7SetPathE6String: 0x405ea1e0 <_ZTv0_n28_N9FileStore7SetPathE6String>: push %ebp 0x405ea1e1 <_ZTv0_n28_N9FileStore7SetPathE6String+1>: mov %esp,%ebp 0x405ea1e3 <_ZTv0_n28_N9FileStore7SetPathE6String+3>: push %ebx 0x405ea1e4 <_ZTv0_n28_N9FileStore7SetPathE6String+4>: sub $0x14,%esp 0x405ea1e7 <_ZTv0_n28_N9FileStore7SetPathE6String+7>: sub $0x8,%esp 0x405ea1ea <_ZTv0_n28_N9FileStore7SetPathE6String+10>: pushl 0xc(%ebp) 0x405ea1ed <_ZTv0_n28_N9FileStore7SetPathE6String+13>: mov 0x8(%ebp),%eax 0x405ea1f0 <_ZTv0_n28_N9FileStore7SetPathE6String+16>: mov (%eax),%edx 0x405ea1f2 <_ZTv0_n28_N9FileStore7SetPathE6String+18>: sub $0x1c,%edx 0x405ea1f5 <_ZTv0_n28_N9FileStore7SetPathE6String+21>: mov 0x8(%ebp),%eax 0x405ea1f8 <_ZTv0_n28_N9FileStore7SetPathE6String+24>: add (%edx),%eax 0x405ea1fa <_ZTv0_n28_N9FileStore7SetPathE6String+26>: push %eax 0x405ea1fb <_ZTv0_n28_N9FileStore7SetPathE6String+27>: call 0x405ea240 <_ZN9FileStore7SetPathE6String> ^ this is where the thunk calls the real function 0x405ea200 <_ZTv0_n28_N9FileStore7SetPathE6String+32>: add $0x10,%esp 0x405ea203 <_ZTv0_n28_N9FileStore7SetPathE6String+35>: sub $0xc,%esp 0x405ea206 <_ZTv0_n28_N9FileStore7SetPathE6String+38>: pushl 0xc(%ebp) 0x405ea209 <_ZTv0_n28_N9FileStore7SetPathE6String+41>: call 0x405ae688 <_ZN6StringD1Ev> ^ what is this doing in the thunk? ^ where it the corresponding constructor called? ^ (clue: it isn't!) 0x405ea20e <_ZTv0_n28_N9FileStore7SetPathE6String+46>: add $0x10,%esp 0x405ea211 <_ZTv0_n28_N9FileStore7SetPathE6String+49>: jmp 0x405ea238 <_ZTv0_n28_N9FileStore7SetPathE6String+88> 0x405ea213 <_ZTv0_n28_N9FileStore7SetPathE6String+51>: nop 0x405ea214 <_ZTv0_n28_N9FileStore7SetPathE6String+52>: mov %eax,0xfffffff8(%ebp) 0x405ea217 <_ZTv0_n28_N9FileStore7SetPathE6String+55>: mov 0xfffffff8(%ebp),%ebx 0x405ea21a <_ZTv0_n28_N9FileStore7SetPathE6String+58>: sub $0xc,%esp 0x405ea21d <_ZTv0_n28_N9FileStore7SetPathE6String+61>: pushl 0xc(%ebp) 0x405ea220 <_ZTv0_n28_N9FileStore7SetPathE6String+64>: call 0x405ae688 <_ZN6StringD1Ev> 0x405ea225 <_ZTv0_n28_N9FileStore7SetPathE6String+69>: add $0x10,%esp 0x405ea228 <_ZTv0_n28_N9FileStore7SetPathE6String+72>: mov %ebx,0xfffffff8(%ebp) 0x405ea22b <_ZTv0_n28_N9FileStore7SetPathE6String+75>: sub $0xc,%esp 0x405ea22e <_ZTv0_n28_N9FileStore7SetPathE6String+78>: pushl 0xfffffff8(%ebp) 0x405ea231 <_ZTv0_n28_N9FileStore7SetPathE6String+81>: call 0x4093f400 0x405ea236 <_ZTv0_n28_N9FileStore7SetPathE6String+86>: mov %esi,%esi 0x405ea238 <_ZTv0_n28_N9FileStore7SetPathE6String+88>: mov 0xfffffffc(%ebp),%ebx 0x405ea23b <_ZTv0_n28_N9FileStore7SetPathE6String+91>: leave 0x405ea23c <_ZTv0_n28_N9FileStore7SetPathE6String+92>: ret End of assembler dump. Do let me know if there is any more information we can provide to help fix this! Best Regards, DH -------------------------------------- David Hanney Chief Technical Officer http://www.digitalbrain.com [UK+44] (0)1273 201704 ----- End forwarded message -----
next reply other threads:[~2002-01-28 1:46 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-01-27 17:46 Craig Rodrigues [this message] -- strict thread matches above, loose matches on Subject: below -- 2001-09-02 1:26 rodrigc 2001-08-05 20:06 simong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020128014606.3180.qmail@sources.redhat.com \ --to=rodrigc@mediaone.net \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).