From: Pedro Alves <pedro@codesourcery.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org, dgraham@nortel.com
Subject: Re: RFC: Do not try g-packet-guess algorithm on exited targets
Date: Mon, 24 Nov 2008 14:49:00 -0000 [thread overview]
Message-ID: <200811232211.59013.pedro@codesourcery.com> (raw)
In-Reply-To: <20081123211454.GA17391@caradoc.them.org>
On Sunday 23 November 2008 21:14:54, Daniel Jacobowitz wrote:
> static const struct target_desc *
> remote_read_description (struct target_ops *target)
> {
> + struct remote_state *rs = get_remote_state ();
> struct remote_g_packet_data *data
> = gdbarch_data (target_gdbarch, remote_g_packet_data_handle);
>
> + /* Do not try this during initial connection. */
> + if (rs->tdesc_no_register_access)
> + return NULL;
> +
Is this new flag working around that fact that remote_open_1 does this?
/* Assume that the target is running, unless we learn otherwise. */
target_mark_running (target);
If we change the logic around to:
/* Assume that the target is not running, unless we learn
otherwise. */
if (extended_p)
target_mark_exited (target);
Then would this in remote_read_description work instead of a
new flag?
> + /* Do not try this during initial connection. */
> + if (!target_has_execution || ptid_equal (inferior_ptid, null_ptid))
> + return NULL;
(or just null_ptid).
I've done that change locally just a few days ago because I found out
that the bit in remote_start_remote that does:
if (gdbarch_has_global_solist (target_gdbarch))
solib_add (NULL, args->from_tty, args->target, auto_solib_add);
also ended up trying to do things to a non-existant inferior due
to target_has_execution being true while that is a lie in the
'extended-remote without an inferior yet' case.
--
Pedro Alves
next prev parent reply other threads:[~2008-11-23 22:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 13:53 Daniel Jacobowitz
2008-11-24 14:49 ` Pedro Alves [this message]
2008-11-24 14:49 ` Daniel Jacobowitz
2008-11-24 19:06 ` Daniel Jacobowitz
2008-11-24 19:17 ` Pedro Alves
2008-11-24 20:11 ` Daniel Jacobowitz
2008-12-01 22:10 ` Michael Snyder
2008-12-01 22:18 ` Daniel Jacobowitz
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=200811232211.59013.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=dgraham@nortel.com \
--cc=drow@false.org \
--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