From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5353 invoked by alias); 5 Feb 2015 16:24:00 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 5324 invoked by uid 48); 5 Feb 2015 16:23:59 -0000 From: "antoine.tremblay at ericsson dot com" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string Date: Thu, 05 Feb 2015 18:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: 7.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: antoine.tremblay at ericsson dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: antoine.tremblay at ericsson dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q1/txt/msg00195.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16551 --- Comment #1 from Antoine Tremblay --- After some research in gdb it seems to me that the expectation is that if a command fails gdb returns to prompt in it's current execution state. The expectation of the developer should be that if a command input is wrong, gdb can't do what the user requested and control is returned to the developer to fix the error. This seems consistent accross all commands in gdb... I think changing that a dprintf fails with an error to a warning and allowing the program to continue could break this consistency and be more trouble for the developer as he won't be given a chance to fix the issue as soon as possible during his debugging session. He would have to wait until the end of the execution. Also, the fact that he called exec-run only gives the developer the expectation that gdb will continue until it reaches a breakpoint, and a dprintf is consired a breakpoint in that sense, so it should not be unexpected for the developer that dprintf can stop the execution in case of failure. I'm also uncertain about what you mean by the stopped event beeing missed ? As dprintf is called by a stop event... Also bug 15185 would not fix the isssue since we can only know about the bad symbol at the runtime of that line since shared libraries could be loaded dynamicaly thus we can't prevalidate the dprintf input as we enter it. -- You are receiving this mail because: You are on the CC list for the bug.