From: Yao Qi <yao@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/2] Fix error when GDB connects to GDBserver with qC disabled
Date: Fri, 25 Jan 2013 10:44:00 -0000 [thread overview]
Message-ID: <510261A5.1080200@codesourcery.com> (raw)
In-Reply-To: <510169A9.7090002@redhat.com>
On 01/25/2013 01:04 AM, Pedro Alves wrote:
> First, this removes the remote_notice_new_inferior call in
> the case the target doesn't send any expedited registers.
> That is, the call is conditional on "if (stop_reply->regcache)".
>
My intention was to move "remote_notice_new_inferior" before the block
"if (stop_reply->regcache)". Don't know why moved it into the block.
> Second, the point of the get_thread_arch_regcache call is to
> pre-fill the regcache with the expedite register values, before
> any other code needs one of the likely registers in the expedited
> set (usually PC, SP, FP), thus saving a roundtrip.
> I haven't checked if notice_new_inferior (the core function) ends
> needing to fetch up registers; it's possible it ends up fetching
> the whole g set anyway, but still, it doesn't feel right.
So the rationale here is to prefer to use expedite registers in the stop
reply, and postpone or even avoid fetching the whole registers by 'g'
packet, right?
>
> This means that if we have a "Txx thread: ptid" reply, then we
> don't really need qC... That's what the patch below does.
> The patch still tries qC first, but I'm thinking we can flip that
> around, and only try qC if the stop reply didn't include a thread.
Why don't we do in this way?
> /* Query the remote target for which is the current thread/process,
> add it to our tables, and update INFERIOR_PTID. The caller is
> responsible for setting the state such that the remote end is ready
> - to return the current thread. */
> + to return the current thread.
> +
> + This function is called after handling the '?' or 'vRun' packets,
> + whose response is a stop reply from which we can also try
> + extracting the thread. If the target doesn't support the explicit
> + qC query, we infer the current thread from that stop reply, passed
> + in in WAIT_STATUS, which may be NULL. */
redundant "in"?
The patch looks right to me. Thanks.
--
Yao (é½å°§)
next prev parent reply other threads:[~2013-01-25 10:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 8:36 Yao Qi
2013-01-23 8:36 ` [PATCH 2/2] Don't query stub if the pid is faked Yao Qi
2013-01-24 17:23 ` Pedro Alves
2013-01-24 17:05 ` [PATCH 1/2] Fix error when GDB connects to GDBserver with qC disabled Pedro Alves
2013-01-25 10:44 ` Yao Qi [this message]
2013-01-25 17:30 ` Pedro Alves
2013-01-25 17:41 ` Pedro Alves
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=510261A5.1080200@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/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