From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6194 invoked by alias); 14 Sep 2004 16:07:37 -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 5839 invoked from network); 14 Sep 2004 16:07:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Sep 2004 16:07:31 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8EG7VRD015012 for ; Tue, 14 Sep 2004 12:07:31 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8EG7Tr13742; Tue, 14 Sep 2004 12:07:30 -0400 To: gdb@sources.redhat.com Subject: breakpoints in C++ constructors From: Jim Blandy Date: Tue, 14 Sep 2004 16:07:00 -0000 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: 2004-09/txt/msg00101.txt.bz2 I've been spending some time looking into getting breakpoints in C++ constructors to work right, but I don't have much to say about it yet. But if there are other people who have thoughts about this, let's talk about it. The essential problem is that a single source construct --- a constructor body for some class C --- gets split into two separate machine-language functions: one to be used when constructing a direct instance of class C (the "in charge" constructor), and one to be used when constructing an instance of some class derived from C (the "not in charge" constructor), to initialize the portion of the object that corresponds to the C subclass. In the following thread, Daniel Jacobowitz and Michael Chastain talked about the user interface implications of constructing distinct names for the two instances of the constructor: http://sources.redhat.com/ml/gdb/2004-07/msg00161.html Daniel has done some work on the breakpoint code to separate the structures that track machine-level breakpoints (either hardware support or patched instructions) from user-level breakpoints. The original intention was to extend this to allow a single user breakpoint to cover multiple machine-code locations, but that change hasn't been made yet: the code still assumes a one-to-one relationship. Completing this would be the natural way to support constructor breakpoints. The MI format for breakpoints would need to change to report the addresses as a list, and the test cases adapted accordingly. The symbol table code would need to be adapted to return multiple addresses for a given source location. Since a given source line can be split into many runs of machine code, a source line may, in general, appear any number of times in the line tables; we currently just return the first entry we find, and hope that's appropriate. To accomodate constructors, we might consider returning a sal for the first line table entry for a given source location in each machine- level function: if a given source line appears nine times in three separate machine-level functions, we could return a list of three sals reporting the first occurrence of the line in each function.