From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17120 invoked by alias); 4 Sep 2008 12:12:30 -0000 Received: (qmail 17108 invoked by uid 22791); 4 Sep 2008 12:12:29 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Sep 2008 12:11:43 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 460FC98418; Thu, 4 Sep 2008 12:11:41 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EA93898417; Thu, 4 Sep 2008 12:11:40 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KbDga-0007DX-0B; Thu, 04 Sep 2008 08:11:40 -0400 Date: Thu, 04 Sep 2008 12:12:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: target_find_description question Message-ID: <20080904121139.GA27200@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <200809022347.m82NluUS012008@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809022347.m82NluUS012008@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-09/txt/msg00062.txt.bz2 On Wed, Sep 03, 2008 at 01:47:56AM +0200, Ulrich Weigand wrote: > Hi Dan, > > in testing the Cell debugger, I came across the question how to handle > target_find_description for native (inf-ptrace) targets. As I understand > it, the idea is to determine the target description *before* any access > to target registers happens. That's right. The remote target used to have a similar problem to the one you describe, and before final merge I redid bits of it in order to move target description reads earlier. > But it seems a proper fix should be rather to call target_find_description > earlier, indeed before any register access happens. Unfortunately this > is a bit awkward as it would mean that either startup_inferior can no > longer just call wait_for_inferior, or else that there would need to > be special handling for this case in wait_for_inferior ... > > Do you have any suggestions how best to handle this? target_find_description currently has a global flag, target_desc_fetched, which means that reading the description multiple times is harmless. The flag will need to become per-target in a multi-target GDB, of course. So it's OK to call target_find_description by hand at an earlier point, before any register access. Unfortunately we're supposed to do that when the target is stopped. Otherwise, any check which attempts to read the registers or aux vector will not work. I suppose the easiest thing to do would be to call target_find_description right before handle_inferior_event, and rely on target_desc_fetched to prevent duplicate work. -- Daniel Jacobowitz CodeSourcery