From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12801 invoked by alias); 18 Sep 2008 21:37:47 -0000 Received: (qmail 12793 invoked by uid 22791); 18 Sep 2008 21:37:47 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Sep 2008 21:37:12 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m8ILaJYI001621; Thu, 18 Sep 2008 17:36:40 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m8ILa8R0027904; Thu, 18 Sep 2008 17:36:09 -0400 Received: from lindt.uglyboxes.com (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m8ILa5q9013019; Thu, 18 Sep 2008 17:36:06 -0400 Message-ID: <48D2C9C5.5030304@redhat.com> Date: Fri, 19 Sep 2008 08:20:00 -0000 From: Keith Seitz User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: John Fine CC: insight@sourceware.org Subject: Re: Can't debug x86_64 C++ programs. References: <48D024D1.3000107@verizon.net> <48D0A482.8060000@redhat.com> <48D12E6A.5030804@verizon.net> <48D1342F.7040703@redhat.com> <48D15FD3.8020802@verizon.net> In-Reply-To: <48D15FD3.8020802@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00070.txt.bz2 John Fine wrote: > So I wasted lots of time trying to use > fprintf_unfiltered (gdb_stdlog, > > Then I realized most of those were just trying to pop up in a window > when Insight crashed, so I would never get to see them. Yeah, the *_unfilitered and *_filtered all head through uiout, which are redirected to insight and tcl/tk. As you discovered, you need to use "normal" printfs. > I think architecture_changed_event OUGHT to call > setup_architecture_data, but I can't tell from the source code what it > actually does or who calls setup_architecture_data. Here's what going on. When you load your x86_64 executable, gdb notices that this is different from the current i386 architecture, so it changes the current architecture to i386:x86_64. When this is changed, an observer notification is fired off from deprecated_current_gdbarch_select_hack (deprecated? I guess gdb doesn't want anyone to know that the architecture has changed??). Insight registers gdbtk_architecture_changed as the observer callback. This then calls the Tcl procedure gdbtk_tcl_architecture_changed, which dispatches this event to the windows. The register window is currently the only window that does anything with this event. It calls the proc gdb_reg_arch_changed, which is aliased to the C function setup_architecture_data. [Phew!] So, alas, setup_architecture_data *is* being called. This will require further investigation. Keith