From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20263 invoked by alias); 6 Feb 2009 01:31:07 -0000 Received: (qmail 20250 invoked by uid 22791); 6 Feb 2009 01:31:05 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BARRACUDA_BRBL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f17.google.com (HELO mail-ew0-f17.google.com) (209.85.219.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Feb 2009 01:30:54 +0000 Received: by ewy10 with SMTP id 10so846616ewy.0 for ; Thu, 05 Feb 2009 17:30:52 -0800 (PST) Received: by 10.67.10.8 with SMTP id n8mr3185660ugi.81.1233883851903; Thu, 05 Feb 2009 17:30:51 -0800 (PST) Received: from pedro-laptop-dell (bl7-247-209.dsl.telepac.pt [85.240.247.209]) by mx.google.com with ESMTPS id o24sm30448ugd.27.2009.02.05.17.30.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 17:30:51 -0800 (PST) Received: by pedro-laptop-dell (Postfix, from userid 1000) id 5B5AAEAEE0; Fri, 6 Feb 2009 01:31:01 +0000 (WET) To: gdb-patches@sourceware.org Subject: [commit] Fix gdb crashes when using target extended-remote against linux gdbserver. Message-Id: <20090206013101.5B5AAEAEE0@pedro-laptop-dell> Date: Fri, 06 Feb 2009 01:31:00 -0000 From: Pedro Alves X-IsSubscribed: yes 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: 2009-02/txt/msg00144.txt.bz2 Currently, if you try debugging against a linux gdbserver in extended-remote, gdb will crash as soon as you attach or run a program that is threaded. The problem is that the thread-db target is loading itself when connected to the extended-remote target, even though it has checks in place to not do that. linux-thread-db.c assumes it is sitting on top of linux-nat.c, and accesses some of its data structures structures and functions directly. In any case, we don't want to use it against gdbserver. The check in linux-thread-db.c that should be preventing thread-db to push itself is this: /* Don't attempt to use thread_db for remote targets. */ if (!target_can_run (¤t_target)) return; But, due to a recent-ish change, remote.c is returning true to target_can_run, if connected in extended-remote mode. The predicate used in this check here, is, strictly speaking, a hack, given that extended-remote *can* run, but, it worked before ... The reason that extended-remote target was adapted to return true when connected, lies in the target_get_osdata query, the call behind the "info os processes" command. What target_get_osdata is trying to do, is check if it is connected to a target that can answer the TARGET_OBJECT_OSDATA call already, and use if if so. If it isn't, then try the query on the default run target. Now, looking at it again, the target_can_run check isn't right for target_get_osdata anyway. TARGET_OBJECT_OSDATA will serve for more things in the future, not just listing processes, and, if we are connected already to a plain (non-extended) remote target that *can't* "run" or "attach", we still want to use it for the TARGET_OBJECT_OSDATA query, not the native target. As an example, currently, if you connect with "target remote", and do "info os processes", you get the list of the processes running on your host computer running gdb, not on the list of processes on the remote computer... So, this changes target_get_osdata to do what it intends to, and, in the process makes connecting to a extended-remote linux gdbserver not crash gdb, by reverting the culprit change to remote.c. We can handle coming up with a better predicate for linux-thread-db.c some other time... Checked in. 2009-02-06 Pedro Alves * remote.c (extended_remote_can_run): Delete. (init_remote_ops): Don't register it. * target.c (target_get_osdata): Don't check for target_can_run. Instead any target that has already been pushed, otherwise fallback to the default run target.. --- gdb/remote.c | 10 ---------- gdb/target.c | 11 ++++------- 2 files changed, 4 insertions(+), 17 deletions(-) Index: src/gdb/remote.c =================================================================== --- src.orig/gdb/remote.c 2009-02-06 00:55:23.000000000 +0000 +++ src/gdb/remote.c 2009-02-06 00:55:34.000000000 +0000 @@ -8674,15 +8674,6 @@ remote_supports_multi_process (void) return remote_multi_process_p (rs); } -static int -extended_remote_can_run (void) -{ - if (remote_desc != NULL) - return 1; - - return 0; -} - static void init_remote_ops (void) { @@ -8768,7 +8759,6 @@ Specify the serial device it is connecte extended_remote_ops.to_detach = extended_remote_detach; extended_remote_ops.to_attach = extended_remote_attach; extended_remote_ops.to_kill = extended_remote_kill; - extended_remote_ops.to_can_run = extended_remote_can_run; } static int Index: src/gdb/target.c =================================================================== --- src.orig/gdb/target.c 2009-02-06 00:55:23.000000000 +0000 +++ src/gdb/target.c 2009-02-06 00:55:34.000000000 +0000 @@ -2218,18 +2218,15 @@ target_get_osdata (const char *type) char *document; struct target_ops *t; - if (target_can_run (¤t_target)) - t = ¤t_target; - else + if (current_target.to_stratum == dummy_stratum) t = find_default_run_target ("get OS data"); + else + t = current_target.beneath; if (!t) return NULL; - document = target_read_stralloc (t, - TARGET_OBJECT_OSDATA, - type); - return document; + return target_read_stralloc (t, TARGET_OBJECT_OSDATA, type); } static int