From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29741 invoked by alias); 18 Sep 2008 22:11:57 -0000 Received: (qmail 29727 invoked by uid 22791); 18 Sep 2008 22:11:56 -0000 X-Spam-Check-By: sourceware.org Received: from vms046pub.verizon.net (HELO vms046pub.verizon.net) (206.46.252.46) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Sep 2008 22:11:11 +0000 Received: from [10.10.1.168] ([209.190.166.162]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K7E00CJVWALKH51@vms046.mailsrvcs.net> for insight@sourceware.org; Thu, 18 Sep 2008 17:11:10 -0500 (CDT) Date: Fri, 19 Sep 2008 13:27:00 -0000 From: John Fine Subject: Re: Can't debug x86_64 C++ programs. In-reply-to: <48D2C9C5.5030304@redhat.com> To: Keith Seitz Cc: insight@sourceware.org Message-id: <48D2D1F4.4060208@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <48D024D1.3000107@verizon.net> <48D0A482.8060000@redhat.com> <48D12E6A.5030804@verizon.net> <48D1342F.7040703@redhat.com> <48D15FD3.8020802@verizon.net> <48D2C9C5.5030304@redhat.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) 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/msg00071.txt.bz2 Keith Seitz wrote: > > Insight registers gdbtk_architecture_changed as the observer callback. That's the part I didn't have a clue about, so you've given me at least the name I can grep for to get a clue. > 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. But I had a printf in setup_architecture_data, so I can be quite sure it is only called the first time (for the architecture with 50 registers) and it is not called the second time (for the architecture with 58 registers). I'm a bit confused that i386 has as many as 50 registers and much more confused that AMD64 has only 8 more than i386. I know for sure about 16 registers that are not in i368 but are part of AMD64 (and are working correctly in the registers window, now that I kludged around the memory clobber). But that 58 vs. 50 issue is just idle curiosity. The big question is how you avoid the memory clobber. Is setup_architecture_data really called twice for 50 registers the first time and 58 the second? Or does your copy start in AMD64 architecture? Or does your memory allocation land differently, so the memory clobber happens without symptom? Or what? Is the fact that my copy of Insight was built with gcc 3.4.6 more significant than the fact that some of my target programs were built with gcc 3.4.6? The group with which my project needs to keep gcc version compatibility is about to switch version, I think to 4.1.2. We have that version of gcc already installed here, but not as the default. I'm not very expert in Linux. So I know how to pick a non default version of gcc for our own projects built with bjam, but I don't know how to do it for a source package like Insight, with its rather complicated makefile. Tomorrow I'll look into building both Insight and Oprofile with the newer gcc.