From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14266 invoked by alias); 14 Feb 2012 10:16:03 -0000 Received: (qmail 14252 invoked by uid 22791); 14 Feb 2012 10:16:01 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Feb 2012 10:15:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1EAFhA2024743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2012 05:15:43 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1EAFfnP003666; Tue, 14 Feb 2012 05:15:42 -0500 Message-ID: <4F3A344D.7080003@redhat.com> Date: Tue, 14 Feb 2012 10:16:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Yao Qi CC: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch 1/8] Generalize interaction with agent in gdb/gdbserver References: <4F1D55D7.7030506@codesourcery.com> <4F1D62D3.2080805@codesourcery.com> <4F341C89.40501@redhat.com> <4F39C9B3.9010005@codesourcery.com> In-Reply-To: <4F39C9B3.9010005@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00257.txt.bz2 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=, nfds=, timeout=) 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