public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "antoine.tremblay at ericsson dot com" <sourceware-bugzilla@sourceware.org>
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	[thread overview]
Message-ID: <bug-16551-4717-tdfCgcZ1qE@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16551-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

--- Comment #1 from Antoine Tremblay <antoine.tremblay at ericsson dot com> ---
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.


  parent reply	other threads:[~2015-02-05 16:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 18:18 [Bug breakpoints/16551] New: " marc.khouzam at ericsson dot com
2014-04-06  4:11 ` [Bug breakpoints/16551] " malaperle at gmail dot com
2015-02-05 16:24 ` antoine.tremblay at ericsson dot com
2015-02-05 18:23 ` antoine.tremblay at ericsson dot com [this message]
2015-02-05 18:24 ` marc.khouzam at ericsson dot com
2015-03-24 17:30 ` antoine.tremblay at ericsson dot com
2015-03-24 20:08 ` marc.khouzam at ericsson dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-16551-4717-tdfCgcZ1qE@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).