From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26045 invoked by alias); 29 Apr 2016 12:10:48 -0000 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 Received: (qmail 26035 invoked by uid 89); 29 Apr 2016 12:10:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1944, agent X-HELO: mail-pf0-f177.google.com Received: from mail-pf0-f177.google.com (HELO mail-pf0-f177.google.com) (209.85.192.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 29 Apr 2016 12:10:37 +0000 Received: by mail-pf0-f177.google.com with SMTP id 77so14681963pfv.2 for ; Fri, 29 Apr 2016 05:10:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6CWBh3xnyGdeuwOtTTQxcsBoWT3iuMER+P+daapT1TU=; b=kKdo891hiIKLK/sfJkWr9YqIhFQa1oZ8Xn9LVDU1BUQU/UG32QuIudL+OK6Pe2Vy8F WfMJ1B3aQJ5cYb9DYio0jBdSWQOdFPfFZWTo2nzdiWt8HmMVuruvm3aaBQCSadybsdS8 BuxEgLyPWlcZ24VvcAGMJYd9KahKQlNOIbi8BB5u8Qu11kSrT0m/l0ZkBxrWLqX65Xjr /wJHTVcG7pyrvo4oh6yIyznDihrZay+LYjbr3wQ+IiQ0SYtfZD+FB8mAxUC1pwLCUlk+ VxGu4vt9mYe4gMLCbHWxFRW/C3BuOlX1xNkTCjX32tB1EBoKvzCXpXXi+DFSt1PTxizk knmg== X-Gm-Message-State: AOPr4FUxMxve4AI2MusQChWgR4e5juSlkiGQx6SmoJVOuSmGErOajrt/Yk7QGquG1yerpA== X-Received: by 10.98.75.10 with SMTP id y10mr28590790pfa.32.1461931835801; Fri, 29 Apr 2016 05:10:35 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id lg8sm5280674pab.48.2016.04.29.05.10.32 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 29 Apr 2016 05:10:34 -0700 (PDT) From: Yao Qi To: Simon Marchi Cc: Subject: Re: [PATCH] ftrace: Fix gdbserver crash when doing tstatus after detach or process exit References: <1459344024-2260-1-git-send-email-simon.marchi@ericsson.com> Date: Fri, 29 Apr 2016 12:10:00 -0000 In-Reply-To: <1459344024-2260-1-git-send-email-simon.marchi@ericsson.com> (Simon Marchi's message of "Wed, 30 Mar 2016 09:20:24 -0400") Message-ID: <86h9ekehu2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00651.txt.bz2 Simon Marchi writes: > A first solution that comes to mind is to make agent_loaded_p check if > current_thread is NULL, and return false if that's the case. It would > make sense, since if there is no current thread, the agent can't > possibly be loaded. However, that would require adding some > #ifdef GDBSERVER to the common code, which is not acceptable. > > An alternative would be to use > > current_thread !=3D NULL && agent_loaded_p () > > wherever agent_loaded_p () is used. However, I find it error prone > for future uses of agent_loaded_p (), since it would be easy to forget > to check for current_thread. > > Instead, the solution I chose is to clear the > all_agent_symbols_looked_up flag whenever we have no more current thread > (process exit or detach). I am not 100% sure it's correct, as there > might be valid situations I don't know about where the agent is loaded > but current_thread =3D=3D NULL, so please correct me if I'm wrong. > Alternatively, we can check (current_thread =3D=3D NULL) in every cmd_q* functions in traceppoint.c, since we've done so in cmd_qtminftpilen and cmd_qtinit. > > Finally, as a side-note, and just to make sure I understand correctly: > since there is a single global all_agent_symbols_looked_up flag, I guess > the tracking of whether the agent is loaded is not expected to work > correctly in a multi-process scenario, is that right? If there are two > processes under gdbserver, there could be one with and one without the > agent. So ideally (as it would be more "right" than the current patch), > I suppose we should track this per-process? > I don't think multi-process tracepoint and fast tracepoint is supported. > +# Compile the test case with the in-process agent library. > +set libipa [get_in_proc_agent] > +gdb_load_shlibs $libipa gdb_load_shlib --=20 Yao (=E9=BD=90=E5=B0=A7)