From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5900 invoked by alias); 4 Sep 2008 21:52:14 -0000 Received: (qmail 5892 invoked by uid 22791); 4 Sep 2008 21:52:14 -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 21:51:35 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id B4FF89841A; Thu, 4 Sep 2008 21:51:33 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 8518F98418; Thu, 4 Sep 2008 21:51:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KbMjk-000800-SO; Thu, 04 Sep 2008 17:51:32 -0400 Date: Thu, 04 Sep 2008 21:52:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: target_find_description question Message-ID: <20080904215132.GA30416@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20080904121139.GA27200@caradoc.them.org> <200809041916.m84JGXcr025369@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809041916.m84JGXcr025369@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/msg00077.txt.bz2 On Thu, Sep 04, 2008 at 09:16:33PM +0200, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > > 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. > > Unfortunately, it turns out this doesn't work. Or rather, it works > too well: target_find_description is called after the first stop, > and determines target properties -- while the inferior process is > still executing the shell we're using to start up the real inferior! Whoops. I didn't think of that. > So it'll detect e.g. a 32-bit inferior because the shell is 32-bit, > even though the real inferior is a 64-bit application ... > > I guess we do need to defer target_find_description until after the > real inferior is started. However, we then have the problem of how > to handle those register/memory accessed in the mean time. Shouldn't accessing the shell's registers always be a bug, admitted one that we already have? We don't have symbols for it, we don't support breakpoints in it, et cetera. We used to have some global information about the number of expected traps, but now it's local. > Maybe we can change handle_inferior_event to not do any PC processing > if stop_soon is set? I don't think that will work, e.g. solib-irix.c and various other solib modules run expecting to hit a breakpoint. -- Daniel Jacobowitz CodeSourcery