From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8740 invoked by alias); 10 May 2002 03:44:16 -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 8733 invoked from network); 10 May 2002 03:44:15 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 10 May 2002 03:44:15 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 70A533DB9; Thu, 9 May 2002 23:44:22 -0400 (EDT) Message-ID: <3CDB4216.30607@cygnus.com> Date: Thu, 09 May 2002 20:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Evans Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: does bpstat_print stop printing prematurely? References: <200204152003.NAA11126@casey.transmeta.com> <15547.51222.125386.852824@casey.transmeta.com> <4060-Tue16Apr2002154926+0300-eliz@is.elta.co.il> <15548.25669.770292.567059@casey.transmeta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00093.txt.bz2 > > Assuming one decides to print all breakpoints, either move the > > control for source/frame printing into bpstat_print or pull > > the loop in bpstat_print into normal_stop(). > > Hmmm... another possibility is to do neither. > Instead, with the preprocessing pass in bpstat_print one > could early exit if printit_done is found, otherwise print > all the non-pc breakpoints first, then print all the pc-breakpoints last, > and then return one of `print_stop_action'. > > That's requires a minimal amount of change and feels safest. > The only issue is whether programs that parse the output would > get confused if multiple pc breakpoints get reported. > The source location would still only be printed once so I'm guessing > it's ok, but someone with some knowledge of all the various > programs that parse the output should be consulted. Hmm, Yes, I agree with the comment about not reporting multiple watchpoint trigers is a bug. As for breakpoints, normal behavour is to just report the first real breakpoint - you've previously been advised that you've multiple breakpoints and I'm guessing this [unfortunatly] is behind the early loop exit. The functions that handle bpstat are in bad shape anyway. One function should analyze the stop reason creating the list. A second function should use this list to decide what to print. MI needs this separation to be able to report stop events reliably. Anyway, suggest at least bug-reporting it. Andrew