From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11114 invoked by alias); 17 Aug 2014 19:02:33 -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 11079 invoked by uid 48); 17 Aug 2014 19:02:32 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/17283] gdbserver stops working in non-stop mode Date: Sun, 17 Aug 2014 19:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: 2014-q3/txt/msg00277.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17283 dje at google dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dje at google dot com --- Comment #2 from dje at google dot com --- I agree more clarity is needed here, but first some data points. Re: >Moreover, I expect that target remote can be run async: > target remote -- stops the program, after connecting to remove > target remote & -- doesn't stop the program (implies continue&) "target remote ... &" is not, AIUI, expected to do what you think it does. IOW, "&" has no special meaning to "target remote". [One could entertain the thought of extending "target ..." to handle "&", but that's a separate subject. There are already existing ways to handle some things, so the additional complexity would need to be justified.] "target remote" just establishes a connection with gdbserver, it does not affect the running state of an inferior. Re: >Does gdbserver in fact interrupt the program, when attaching to it, before gdb >connects to it over target remote? Yes it does. If one wants to attach to a running program, and leave it running, one generally uses "target extended-remote ..." and then "attach ... &" from gdb. Re: >Finally, when gdbserver is aware, that it is going to terminate abnormally, [...] >does gdbserver remove all breakpoints? Depending on what form of breakpoint is being used, gdbserver may not even be aware that breakpoints have been asserted. No disagreement that we should be removing breakpoints, just a note to say this will take a bit of cooperation with gdb (to fully handle all possible cases). For a start, gdbserver could at least remove the ones it is aware of. Re: >The same question, about removal off breakpoints, upon unpleasent sitatuations >are recognized: when it happens that gdb offers to write down its core dump, does >it remove all inserted breakpoints and leave the process running furhter? I can't find any code that does this. Easy enough to verify of course. -- You are receiving this mail because: You are on the CC list for the bug.