From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18637 invoked by alias); 16 Sep 2002 17:03:19 -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 18630 invoked from network); 16 Sep 2002 17:03:19 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 16 Sep 2002 17:03:19 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8GH3Gp29597; Mon, 16 Sep 2002 10:03:16 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: Fernando Nasser , Michael Elizabeth Chastain , gdb@sources.redhat.com, Andrew Cagney Subject: Re: Pinging Michael C References: <20020914045436.GA22119@nevyn.them.org> <3D85F0F3.5060108@redhat.com> <20020916150921.GA9184@nevyn.them.org> From: David Carlton Date: Mon, 16 Sep 2002 10:03:00 -0000 In-Reply-To: <20020916150921.GA9184@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00205.txt.bz2 On Mon, 16 Sep 2002 11:09:21 -0400, Daniel Jacobowitz said: > On Mon, Sep 16, 2002 at 10:55:47AM -0400, Fernando Nasser wrote: >> Daniel Jacobowitz wrote: >>> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html >> I wonder if next will relly be more reliable. Anyway, we can try >> -- the test is not about breakpoints. > I hadn't actually looked at this one. David, there's an easier way > - if you look in lib/gdb.exp, gdb_get_line_number. Is that closer > to what you want? It should be more reliable than 'next'ing. Honestly, I don't know if either of them is reliable, as is written. The situation is that m-static.cc constructs a bunch of objects that it doesn't do anything with; m-static.exp tries to stop after each object is constructed, and then examine what the object looks like. And it seems to me that, whether you use next or breakpoints (and whether you do the latter with hard-coded numbers (blech), relative offsets, or with gdb_get_line_number), you're going to run into problems in that GDB might not be willing to stop at every line, and that whether or not it is willing might depend on the specific compiler, compiler options, etc. that are being used. Personally, I don't see any reason why the test shouldn't just construct all the objects before inspecting any of them with GDB. So what makes sense to me would be to put a breakpoint on the return line (using gdb_get_line_number, presumably), run until that, and only then inspect all the objects that have been constructed. But if people don't like that, I'd prefer to stick with the current next'ing (with a break +2 throw in for fun). I think that would be as reliable and easier to maintain than gdb_get_line_number. The latter only makes sense if people might later insert lines that should be skipped in the middle of the extant constructors; that doesn't seem too plausible to me. >> The following ChangeLog entries need some more info though: >> >> * gdb.c++/m-static.cc: Add test 4. >> * gdb.c++/m-static.h: New file. >> * gdb.c++/m-static1.cc: New file. > (Fernando, this is exactly what the GNU coding standards say a > ChangeLog entry should look like - just what changed, not why it was > changed, which belongs only in the code. What else are you looking > for?) I don't mind making them longer, but Andrew yells at me whenever I include long comments. So I'd rather not make the ChangeLog entries more verbose without hearing from him first. >> > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html >> I don't think we want to add tests to make gdb dump core to the >> testsuite right away. It should go in as soon as someone fixes the >> problem to prevent a regression. Alternatively we can add it in and >> explicitly skip the test with a explicit call to the kfail proc... > Fortunately, David has since fixed the bug. I think this patch is > ready to go in, once we agree on ChangeLog formatting. Right, and of course I'll update the comment in the .exp file accordingly. So would it be okay if I changed the test with all the next's to construct all the objects before examining any of them, updated the comments on the one test to reflect the fact that the bug has been fixed, and then check them in? David Carlton carlton@math.stanford.edu