From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32506 invoked by alias); 18 Oct 2006 16:29:13 -0000 Received: (qmail 32498 invoked by uid 22791); 18 Oct 2006 16:29:13 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Oct 2006 16:29:05 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9IGT3Pb123034 for ; Wed, 18 Oct 2006 16:29:03 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9IGVZWW3219710 for ; Wed, 18 Oct 2006 18:31:35 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9IGT2fg000591 for ; Wed, 18 Oct 2006 18:29:02 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id k9IGT2ZX000588; Wed, 18 Oct 2006 18:29:02 +0200 Message-Id: <200610181629.k9IGT2ZX000588@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 18 Oct 2006 18:29:02 +0200 Subject: Re: [RFC] Replace deprecated_target_new_objfile_hook by observer? To: drow@false.org (Daniel Jacobowitz) Date: Wed, 18 Oct 2006 16:29:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sources.redhat.com In-Reply-To: <20061017233524.GA18064@nevyn.them.org> from "Daniel Jacobowitz" at Oct 17, 2006 07:35:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00221.txt.bz2 Daniel Jacobowitz wrote: > There Be Dragons! Note that there is a case where the remote objfile > hook does _not_ call the next thing on the chain. This is somewhat > deliberate, in that it's what prevents thread-db from being enabled > when talking to gdbserver, and somewhat accidental, in that I'm sure it > wasn't meant to work this way. But we'll need to do some rearranging > in order to keep the current state of affairs working. I've run into this in my work on GDB support for the Cell BE (which is getting a lot closer to a state where we can try to submit it, b.t.w.). We're working on providing code overlay support for the Cell SPEs, and to support this in the debugger, I needed to hook into the objfile chain; I ran into exactly the problem you describe above. To fix this, I'm currently using this patch, which attempts to express more directly that linux-thread-db should not be used if the target is remote: diff -urN gdb-orig/gdb/linux-thread-db.c gdb-6.5/gdb/linux-thread-db.c --- gdb-orig/gdb/linux-thread-db.c 2006-05-06 00:42:43.000000000 +0200 +++ gdb-6.5/gdb/linux-thread-db.c 2006-09-25 02:12:11.382901136 +0200 @@ -669,6 +669,10 @@ if (!target_has_execution) return; + /* Don't attempt to use thread_db for remote targets. */ + if (!target_can_run (¤t_target)) + return; + /* Initialize the structure that identifies the child process. */ proc_handle.pid = GET_PID (inferior_ptid); diff -urN gdb-orig/gdb/remote.c gdb-6.5/gdb/remote.c --- gdb-orig/gdb/remote.c 2006-05-05 22:08:45.000000000 +0200 +++ gdb-6.5/gdb/remote.c 2006-09-25 02:12:11.449890952 +0200 @@ -5466,8 +5466,7 @@ remote_check_symbols (objfile); } /* Call predecessor on chain, if any. */ - if (remote_new_objfile_chain != 0 && - remote_desc == 0) + if (remote_new_objfile_chain) remote_new_objfile_chain (objfile); } Does this look reasonable? Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development Ulrich.Weigand@de.ibm.com