This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] mi: Add launch-type={run,attach} in =thread-group-started


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]