* gdb in non-stop/sync mode connects to gdbserver
@ 2012-11-22 16:09 Yao Qi
2012-11-22 18:16 ` Pedro Alves
0 siblings, 1 reply; 3+ messages in thread
From: Yao Qi @ 2012-11-22 16:09 UTC (permalink / raw)
To: gdb
Hello,
When running moribund-step.exp with boardfile 'unix', we'll get two passes,
PASS: gdb.base/moribund-step.exp: set non-stop on
PASS: gdb.base/moribund-step.exp: step
However, when running it with boardilfe native-gdbserver, we'll get only
one pass,
PASS: gdb.base/moribund-step.exp: set non-stop on
in fact, gdb hang there when connecting to gdbserver. Supposing gdb is
in non-stop and sync mode, here is callgraph of functions related to
'connecting to remote gdbserver'.
remote_start_remote
1) putpkt ("QNonStop:1");
2) remote_thread_info
|
+-> remote_notice_new_inferior
|
+-> notice_new_inferior
| |
| +-> target_stop and then wait_for_inferior [A]
+-> attach_command_post_wait
|
+ target_stop (in non-stop mode, and no wait) [B]
3) putpkt ("?")
4) init_wait_for_inferior
5) check packet replied to "?", and handle stop reply if needed.
After step 1), GDBserver knows that "we are in non-stop mode". In step
2), gdb calls target_stop in [A], sending 'vCont;t' to stop one thread,
and expect to get a %Stop notification. However, when gdbserver
launches program, the thread has been stopped before gdb connects to
gdbserver. So the stop request from gdb is ignored by gdbserver (shown
by the gdbserver log below),
getpkt ("vCont;t:p45df.45df"); [no ack sent]
already stopped LWP 17887 at GDB's request
Need step over [LWP 17887]? Ignoring, should remain stopped
Resuming, no pending status or step over needed
putpkt ("$OK#9a"); [noack mode]
and no %Stop notification is sent back to gdb. Then, gdb hang there.
The problem is that gdb wants to get a certain thread stopped, but
doesn't know its state, so has to blindly force to stop it, and expect a
%Stop notification to come. Then, I am wondering if gdbserver can sends
the state of threads, if known, to gdb when gdb connects, and gdb don't
have to stop threads if they are already stopped. Is it a good way to
go? We can achieve this by add new attribute 'state' in the xml
returned to qxfer:threads:read. My experiments show it works, but not
sure if I miss something important.
Doing this is not enough to fix the problem I mentioned at the
beginning. There is another problem in the following steps. Supposing
gdb doesn't call target_stop in [A], gdb will call target_stop in [B],
GDB GDBserver
[B] 'vCont;t' ->
<- 'OK'
3) '?' ->
<- 'T0505:xxxxx'
4)
5) process stop reply and send 'vStopped'
'vStopped' ->
<- 'OK'
This process requires that there is no packet sent in step 4), because
gdb is expecting to get a stop reply. Unfortunately,
breakpoint_init_inferior, called by init_wait_for_inferior, has to
access inferior memory, so 'm' packet is sent out. Looks like the fix
to this problem is to move all functions which cause sending packets in
step 4) after step 5). Does it sound a good idea?
I've got a patch to fix the two problems, but I am not sure it is on a
right direction. If it is correct, I'll polish the patch, and post it.
--
Yao (é½å°§)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gdb in non-stop/sync mode connects to gdbserver
2012-11-22 16:09 gdb in non-stop/sync mode connects to gdbserver Yao Qi
@ 2012-11-22 18:16 ` Pedro Alves
2012-11-23 1:35 ` Yao Qi
0 siblings, 1 reply; 3+ messages in thread
From: Pedro Alves @ 2012-11-22 18:16 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb
On 11/22/2012 04:09 PM, Yao Qi wrote:
> Hello,
> When running moribund-step.exp with boardfile 'unix', we'll get two passes,
>
> PASS: gdb.base/moribund-step.exp: set non-stop on
> PASS: gdb.base/moribund-step.exp: step
>
> However, when running it with boardilfe native-gdbserver, we'll get only one pass,
>
> PASS: gdb.base/moribund-step.exp: set non-stop on
>
> in fact, gdb hang there when connecting to gdbserver. Supposing gdb is in non-stop and sync mode, here is callgraph of functions related to 'connecting to remote gdbserver'.
"non-stop and sync mode" is really not supported. non-stop is defined to
work only with async on. There are many such assumptions in the code. That the
test works in sync mode on native is just an accident.
--
Pedro Alves
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gdb in non-stop/sync mode connects to gdbserver
2012-11-22 18:16 ` Pedro Alves
@ 2012-11-23 1:35 ` Yao Qi
0 siblings, 0 replies; 3+ messages in thread
From: Yao Qi @ 2012-11-23 1:35 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb
On 11/23/2012 02:16 AM, Pedro Alves wrote:
> "non-stop and sync mode" is really not supported. non-stop is defined to
> work only with async on. There are many such assumptions in the code. That the
> test works in sync mode on native is just an accident.
I had a vague impression that "non-stop" works on top of async mode
before. However, I was misled by the code that 'target_can_async_p' is
checked on 'non-stop' path, and accordingly think "non-stop may work on
sync mode". Anyway, thanks for confirming this.
--
Yao (é½å°§)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-11-23 1:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-22 16:09 gdb in non-stop/sync mode connects to gdbserver Yao Qi
2012-11-22 18:16 ` Pedro Alves
2012-11-23 1:35 ` Yao Qi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).