From: Simon Marchi <simon.marchi@ericsson.com>
To: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] mi: Add launch-type={run,attach} in =thread-group-started
Date: Wed, 17 Aug 2016 20:17:00 -0000 [thread overview]
Message-ID: <73625923-bba3-92f6-de2f-110f9d27bb51@ericsson.com> (raw)
In-Reply-To: <20160801211401.18155-3-simon.marchi@ericsson.com>
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
next prev parent reply other threads:[~2016-08-17 20:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 21:14 [PATCH 0/2] Two MI changes related to separate UIs Simon Marchi
2016-08-01 21:15 ` [PATCH 2/2] mi: Add launch-type={run,attach} in =thread-group-started Simon Marchi
2016-08-02 14:49 ` Eli Zaretskii
2016-08-02 15:55 ` Simon Marchi
2016-08-17 20:17 ` Simon Marchi [this message]
2016-08-01 21:15 ` [PATCH 1/2] mi: Restore original thread/frame when specifying --thread or --thread-group Simon Marchi
2016-08-02 14:49 ` Pedro Alves
2016-08-02 17:45 ` Simon Marchi
2016-08-02 22:32 ` Simon Marchi
2016-08-03 13:41 ` Pedro Alves
2016-08-03 22:24 ` Simon Marchi
2016-08-05 17:26 ` Pedro Alves
2016-08-05 21:01 ` Simon Marchi
2016-08-17 20:24 ` Simon Marchi
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=73625923-bba3-92f6-de2f-110f9d27bb51@ericsson.com \
--to=simon.marchi@ericsson.com \
--cc=gdb-patches@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