From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12338 invoked by alias); 4 Sep 2008 19:17:26 -0000 Received: (qmail 12326 invoked by uid 22791); 4 Sep 2008 19:17:25 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Sep 2008 19:16:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m84JGYju087148 for ; Thu, 4 Sep 2008 19:16:34 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.8/8.13.8/NCO v9.0) with ESMTP id m84JGYNG3792920 for ; Thu, 4 Sep 2008 21:16:34 +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 m84JGXVH025372 for ; Thu, 4 Sep 2008 21:16:33 +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 m84JGXcr025369; Thu, 4 Sep 2008 21:16:33 +0200 Message-Id: <200809041916.m84JGXcr025369@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 4 Sep 2008 21:16:33 +0200 Subject: Re: target_find_description question To: drow@false.org (Daniel Jacobowitz) Date: Thu, 04 Sep 2008 19:17:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080904121139.GA27200@caradoc.them.org> from "Daniel Jacobowitz" at Sep 04, 2008 08:11:39 AM 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-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00067.txt.bz2 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! 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. Maybe we can change handle_inferior_event to not do any PC processing if stop_soon is set? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com