From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32205 invoked by alias); 1 Oct 2003 06:57:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32189 invoked from network); 1 Oct 2003 06:57:12 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 1 Oct 2003 06:57:12 -0000 Received: by zenia.home (Postfix, from userid 5433) id F1CB120766; Wed, 1 Oct 2003 01:52:52 -0500 (EST) To: Cc: , Subject: Re: Breakpoints in ctor and gcc 3.x References: <57CE6CB990693A478C1106BBC91398BA7D559D@sxmbx04.corproot.net> From: Jim Blandy Date: Wed, 01 Oct 2003 06:57:00 -0000 In-Reply-To: <57CE6CB990693A478C1106BBC91398BA7D559D@sxmbx04.corproot.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00015.txt.bz2 writes: > This bug is old and I'm surprised that it still has not been fixed > !!! Is there any workaround? When will it be fixed ? I think it is > a serious one since you can't debug your ctor or dtor ! The problem is that GCC emits two copies of a constructor: one that's called to initialize a direct instance of the class (the "in charge" constructor), and one to initialize the class's portion of an instance of some derived class (the "not-in-charge" constructor). They deal with virtual base classes differently, and there may be some other things. But GDB only sets a breakpoint in one copy --- whichever one appears first in the code. At the moment, GDB assumes that each breakpoint set by the user can be implemented by a single break instruction or hardware breakpoint. To handle breakpoints on constructors, you need to set two low-level breakpoints --- one on the in-charge, and one on the not-in-charge. This is going to be a lot of work to fix, and there were other, also serious, C++ bugs folks decided to work on first. Simply knowing the in-charge vs. not-in-charge distinction may help out. For example, if you're trying to debug the constructor for some class's base class, but GDB is setting its breakpoint on the in-charge constructor, you could try instantiating the base class directly, to hit the breakpoint. Or the reverse. You could try setting the breakpoint by raw address: use "disassemble" and x/i to find the code address of the constructor instance you actually want to debug, and use "break *EXPR" to set the breakpoint there.