From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10311 invoked by alias); 26 Jul 2002 21:19:28 -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 10304 invoked from network); 26 Jul 2002 21:19:27 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 26 Jul 2002 21:19:27 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 70CD7D2CBD; Fri, 26 Jul 2002 14:19:26 -0700 (PDT) Date: Fri, 26 Jul 2002 14:19:00 -0000 From: Joel Brobecker To: Fernando Nasser Cc: "William A. Gatliff" , gdb@sources.redhat.com Subject: Re: "tbreak" and "commands" commands... Message-ID: <20020726211926.GK10000@gnat.com> References: <20020726185406.GG10000@gnat.com> <20020726140130.A15935@saturn.billgatliff.com> <20020726203114.GI10000@gnat.com> <3D415F90.BE61E0BD@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D415F90.BE61E0BD@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-07/txt/msg00292.txt.bz2 > Yes, it is a bug anyway. We should either refuse or handle the > commands. OK. I think the right thing to do now is to open a PR. I forgot to mention it in my first message, but I had consulted the database before sending it. > Is there any specific reason you want to delete the breakpoint? > You can just disable it as part of the commands. I can't say for sure, because I am not the one who came across this odd behavior. I was just asked why it id not work... But I think I have an idea. I think they (the persons who found this problem) are using a script to do some regression testing. They know the code with go through certain locations in a certain order. So they put temporary breakpoints one after the other. They make them temporary in order for the previous breakpoints not to interfere during the execution. I don't have a problem rejecting commands on temporary breakpoints. They already use the work-around you suggest of disabling the breakpoint inside the command, but this is a light pain, and may also be prone to error. It seems that there we don't know of any reason at the moment why commands could not work with temporary breakpoints. So I will see if I can fix that. If it turns out to be too complicated, then we can change GDB to refuse commands with temporary breakpoints. Does it sound reasonable? -- Joel