From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66263 invoked by alias); 17 Aug 2016 20:17:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66252 invoked by uid 89); 17 Aug 2016 20:17:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:texinfo, cdt, CDT, intervention X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Aug 2016 20:17:17 +0000 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 3E.0E.02568.537C4B75; Wed, 17 Aug 2016 22:21:10 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.80) with Microsoft SMTP Server id 14.3.301.0; Wed, 17 Aug 2016 16:11:41 -0400 Subject: =?UTF-8?Q?Re:_[PATCH_2/2]_mi:_Add_launch-type=3d{run=2cattach}?= =?UTF-8?Q?=c2=a0in_=3dthread-group-started?= To: References: <20160801211401.18155-1-simon.marchi@ericsson.com> <20160801211401.18155-3-simon.marchi@ericsson.com> From: Simon Marchi Message-ID: <73625923-bba3-92f6-de2f-110f9d27bb51@ericsson.com> Date: Wed, 17 Aug 2016 20:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160801211401.18155-3-simon.marchi@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00175.txt.bz2 On 16-08-01 05:14 PM, Simon Marchi wrote: > For Eclipse CDT to properly handle processes attached or started from > the console, it would be useful to have a hint of whether the > thread-group was started by gdb or attached. In particular, it helps > for inferior pty handling, since a process that is "ran" requires some > special handling for its output to appear in a console in CDT, whereas > an "attached" process doesn't require any intervention. > > This patch adds launch-type="run" or launch-type="attach" to the > =thread-group-started event. "launch" comes from the Eclipse > terminology, so it's perhaps not the best term. It would be nice to > have something that fits better in the gdb terminology. Suggestions are > welcome. I also thought of using attached="{1,0}", but I think the > other approach is more easily extensible if we ever need to. > > Note that launch-type="run" will be present even "starting" a core file. > That's because we display "run" if inferior->attach_flag is 0 and > "attach" otherwise. If that's a problem, we could find a way to omit > the field completely when it's irrelevant. For example, when none of > the target present on the target stack know how to run or attach (which > is the case when inspecting a core file I believe), then it's probably > irrelevant. > > I needed to do some little changes in various targets, so that struct > inferior's attach_flag field is set before inferior_appeared is called. > I can't test all of them, but the changes seem very low risk to me. > > I have added a test for an attach in MI (it seems like there was none), > in which I test =thread-group-started with launch-type="attach". > Testing launch-type="run" could probably be done as well, but would be a > bit more involved (we could perhaps test it as part of > mi_run_cmd_full...). > > Regtested on x86, unix/native-gdbserver/native-extended-gdbserver. > > gdb/ChangeLog: > > * NEWS: Announce new "launch-type" field in =thread-group-started. > * mi/mi-interp.c (mi_inferior_appeared): Output "launch-type" > attribute in =thread-group-started event. > * darwin-nat.c (darwin_attach): Move setting of attach_flag > before call to inferior_appeared. > * gnu-nat.c (gnu_attach): Likewise. > * inf-ptrace.c (inf_ptrace_attach): Likewise. > * nto-procfs.c (procfs_attach): Likewise. > * procfs.c (do_attach): Likewise. > * remote.c (remote_add_inferior): Likewise. > * windows-nat.c (do_initial_windows_stuff): Likewise. > > gdb/doc/ChangeLog: > > * gdb.texinfo (GDB/MI Async Records): Document new "launch-type" field > in =thread-group-started. > > gdb/testsuite/ChangeLog: > > * gdb.mi/mi-attach.exp: New file. > * gdb.mi/mi-attach.c: New file. I am abandoning this for now. Based on this conversation [0], we concluded that the solution we had planned might not be an appropriate user experience. And even then, it had its technical flaws, so it's not clear that this new field will be needed. [0] https://sourceware.org/ml/gdb/2016-08/msg00036.html