From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7836 invoked by alias); 23 Apr 2003 02:09:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7828 invoked from network); 23 Apr 2003 02:09:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 Apr 2003 02:09:01 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3N290D21214 for ; Tue, 22 Apr 2003 22:09:01 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3N28xW01060; Tue, 22 Apr 2003 22:08:59 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h3N28wM08523; Tue, 22 Apr 2003 19:08:58 -0700 Message-ID: <3EA5F5BA.59FF64A4@redhat.com> Date: Wed, 23 Apr 2003 02:42:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] test hand function call in commands list References: <20030414154048.GC1151@gnat.com> <20030416142321.GA7612@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00428.txt.bz2 Daniel Jacobowitz wrote: > > On Mon, Apr 14, 2003 at 11:40:48AM -0400, Joel Brobecker wrote: > > The attached patch to break.exp was written by Klee Dienes and > > submitted in the following message: > > > > http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html > > > > The purpose of the test is to make sure that a problem occuring with > > function calls inside a commands list does not cause a SIGSEGV. > > > > 2003-04-14 J. Brobecker > > > > From Klee Dienne > > * gdb.base/break.exp: Add multiple calls to the inferior in > > the user-commands for 'break 79'. Add a check for the calls > > to the inferior in the check for the result. Add new test, to > > check that user-defined breakpoint commands are called for functions > > called by the user (currently fails). > > > > When I ran the test, I was very surprised to see one FAIL. I am > > describing below the symptoms (no time to investigate this today), but I > > think the test is worthwhile adding anyway. Ok to apply? > > No; let's figure out what the new problem is first. After that let's > get the test in as quickly as possible so that we know if it breaks > again :) > > > Here is a small description of the problem: > > > > The test itself inserted a breakpoint in marker2. It then makes a hand > > function call to this function. Here is the output from the logs: > > > > | print marker2(99) > > | > > | Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49 <<<--- > > | 49 int marker2 (a) int a; { return (1); } > > | The program being debugged stopped while in a function called from GDB. > > | When the function (marker2) is done executing, GDB will silently > > | stop (instead of continuing to evaluate the expression containing > > | the function call). > > > > Klee's patch then adds a commands list to the breakpoint in maker2: > > > > | commands 26 > > | Type commands for when breakpoint 26 is hit, one per line. > > | End with a line saying just "end". > > | >silent > > | >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5) > > | >end > > > > And calls marker2 again: > > > > | print marker2(99) > > | The program being debugged stopped while in a function called from GDB. > > | When the function (marker2) is done executing, GDB will silently > > | stop (instead of continuing to evaluate the expression containing > > | the function call). > > > > The fact that GDB did not print the breakpoint number shows that GDB > > started evaluating the commands list. However, we did not get the > > output from the printf command, which means that the evaluation stopped > > prematurely for some reason. > > > > I will be happy to have a look at this problem sometime in the future. > > But, if somebody else would like to have a look, no problem either. > > I can reproduce this. It's even simpler; we aren't executing the > commands list even if if there's no inferior function call in them. > This appears to be specific to commands on a breakpoint hit during an > inferior function call. > > Did this ever work? It looks like the call to error() when we stop in > call_function_by_hand drops us out in start_event_loop, but the call to > bpstat_do_actions is in command_handler (closer to the innermost end of > the call chain, and thus bypassed by the error()). > > Should we be calling bpstat_do_actions before that error()? It is traditional for an error generated by a command list to cause an abort of the rest of the command list. Someone once requested a mode switch that would suppress that, though.