Re: [patch 1/8] Generalize interaction with agent in gdb/gdbserver

[Pedro Alves <palves at redhat dot com>]

On 02/14/2012 02:40 AM, Yao Qi wrote:
> On 02/10/2012 03:20 AM, Pedro Alves wrote:
>>>> +#ifdef GDBSERVER
>>>> +  /* Need to read response with the inferior stopped.  */
>>>> +  if (!ptid_equal (ptid, null_ptid))
>>>> +    {
>>>> +      int was_non_stop = non_stop;
>>>> +      struct target_waitstatus status;
>>>> +      struct thread_resume resume_info;
>>>> +
>>>> +      /* Stop thread PTID.  */
>>>> +      resume_info.thread = ptid;
>>>> +      resume_info.kind = resume_stop;
>>>> +      resume_info.sig = TARGET_SIGNAL_0;
>>>> +      (*the_target->resume) (&resume_info, 1);
>>>> +
>>>> +      non_stop = 1;
>>>> +      mywait (ptid, &status, 0, 0);
>>>> +      non_stop = was_non_stop;
>>>> +    }
>>>> +#endif
>> Since there's no #else, I take it you haven't really tried using this
>> on GDB, without gdbserver?
>>
> 
> I thought this part can be removed.  

Then that would be a separate change.

> The intention of this part is to really stop "debugging thread", so it is safe 
> to read from command buffer later.  We don't have "debugging thread" stopped,
> because the synchronization of read and write is controlled by socket.  When
> we get here, after reading one byte from socket, "debugging thread" has
> finished executing command, and write return result in command buffer.
> It is being blocked by reading from socket, even it is not stopped.
> GDB/GDBserver can safely read contents out of command buffer without
> having to stop "debugging thread".  Am I missing something here?

It's not really about "safeness".  With ptrace or /proc/PID/mem, you can only read
memory from the inferior is it is ptrace-stopped (stopped by a signal, breakpoint, etc.).
>From ptrace's perpective, even if the thread is blocked reading from a socket,
the thread is running.  Trying to read memory while the thread is running results in
error.  Now, what is happening is that we're actually not reading the command
buffer with the helper thread selected as current thread, but instead we're reading
memory through the thread that was selected at run_inferior_command entry (which is
the thread you have selected in GDB).  And that happens to be stopped.  Try selecting
the helper thread instead:

(gdb) t 3
[Switching to thread 3 (Thread 22463)]
#0  0x0000000000396223 in ?? ()
(gdb) info static-tracepoint-markers
Cnt     ID                                       Enb Address            What
Remote failure reply: E.UST library not loaded in process.  Static tracepoints unavailable.
(gdb)

and things break.

Even if you don't do that, removing that bit breaks gdbserver's track of what is stopped
or not.  Vis:

(gdb) b main
Breakpoint 1 at 0x400aa6: file ../../../src/gdb/testsuite/gdb.trace/strace.c, line 29.
(gdb) c
Continuing.

Breakpoint 1,
main () at ../../../src/gdb/testsuite/gdb.trace/strace.c:29
29        int a = 0;
(gdb) info static-tracepoint-markers
Cnt     ID                                       Enb Address            What
1       metadata/core_marker_format              n   0x00007ffff7bb7692
         Data: "channel %s name %s format %s"
2       metadata/core_marker_format              n   0x00007ffff7bb8897
         Data: "channel %s name %s format %s"
3       metadata/core_marker_id                  n   0x00007ffff7bb957d
         Data: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u"
4       metadata/core_marker_id                  n   0x00007ffff7bb9a04
         Data: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u"
5       metadata/core_marker_id                  n   0x00007ffff7bbb006
         Data: "channel %s name %s event_id %hu int #1u%zu long #1u%zu pointer #1u%zu size_t #1u%zu alignment #1u%u"
6       metadata/core_marker_format              n   0x00007ffff7bbb235
         Data: "channel %s name %s format %s"
7       ust/potential_exec                       n   0x00007ffff7bd8240
         Data: " "
8       ust/bar                                  n   0x0000000000400ab3 in main at ../../../src/gdb/testsuite/gdb.trace/strace.c:32
         Data: "str %s"
9       ust/bar2                                 n   0x0000000000400afb in main at ../../../src/gdb/testsuite/gdb.trace/strace.c:33
         Data: "number1 %d number2 %d"
10      ust/dummymark                            n   0x0000000000400b6c
         Data: " "
(gdb) info threads
[New Thread 22690]
[New Thread 22691]
  Id   Target Id         Frame
  3    Thread 22691      0x0000000000653023 in ?? ()
  2    Thread 22690      0x000000339e6e6af3 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
* 1    Thread 22681      main () at ../../../src/gdb/testsuite/gdb.trace/strace.c:29
(gdb)

Look at what's shown in gdbserver's console:

 Listening on port 9999
 Remote debugging from host 127.0.0.1
 ptrace(regsets_fetch_inferior_registers) PID=22691: No such process
 ptrace(regsets_fetch_inferior_registers) PID=22691: No such process

"No such process" also means "the process exists but was not stopped".

$ cat /proc/22681/task/*/status | grep State
State:  t (tracing stop)
State:  t (tracing stop)
State:  S (sleeping)

That is, gdbserver got confused and tried to read registers from 22691 thinking it was
stopped, but it wasn't.  And 22691 is thread 3, which is the helper thread.
Things go downhill from here.

> I get rid of this part from its original place (gdbserver/tracepoint.c),
> and run gdb.trace/strace.exp.  Results look unchanged.

For the reasons explained above.

-- 
Pedro Alves