From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18183 invoked by alias); 4 Nov 2003 00:38:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18170 invoked from network); 4 Nov 2003 00:37:59 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sources.redhat.com with SMTP; 4 Nov 2003 00:37:59 -0000 Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hA40babe042474; Mon, 3 Nov 2003 16:37:36 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id hA40bZP9084300; Mon, 3 Nov 2003 16:37:35 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hA40bZsm084299; Mon, 3 Nov 2003 16:37:35 -0800 (PST) (envelope-from marcel) Date: Tue, 04 Nov 2003 00:38:00 -0000 From: Marcel Moolenaar To: "J. Johnston" Cc: kettenis@gnu.org, gdb@sources.redhat.com Subject: Re: Problem with deprecated_select_gdbarch_hack Message-ID: <20031104003735.GA84210@dhcp01.pn.xcllnt.net> References: <3FA6EC40.8060007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA6EC40.8060007@redhat.com> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-11/txt/msg00022.txt.bz2 On Mon, Nov 03, 2003 at 07:01:04PM -0500, J. Johnston wrote: > Mark, > > The current mainline gdb fails for ia64 linux due to an assertion in > deprecated_select_gdbarch_hack(). I noticed you added this code recently. > I have attached a scripted session with set debug arch 1. Can you verify > if the debug messages indicate any unanticipated path through your code? I > am just trying to debug a simple "hello world" program. I noticed it too. The gdb_assert() in deprecated_select_gdbarch_hack() is faulty because gdbarch_update_p() does not necessarily change the current gdbarch to the one passed to deprecated_select_gdbarch_hack(). It can leave the gdbarch unchanged if it's semantically equivalent to the one asked to change to. Removal of the faulty gdb_assert() should do the trick. ... > gdbarch_update: info.bfd_arch_info ia64-elf64 > gdbarch_update: info.byte_order 1 (little) > gdbarch_update: info.osabi 5 (GNU/Linux) > gdbarch_update: info.abfd 0x60000000000f16b0 > gdbarch_update: info.tdep_info 0x0 > gdbarch_update: New architecture 0x6000000000102590 (ia64-elf64) selected ... > gdbarch_update: info.bfd_arch_info ia64-elf64 > gdbarch_update: info.byte_order 1 (little) > gdbarch_update: info.osabi 5 (GNU/Linux) > gdbarch_update: info.abfd 0x0 > gdbarch_update: info.tdep_info 0x0 > gdbarch_update: Previous architecture 0x60000000000b2620 (ia64-elf64) selected > gdbarch_update: info.bfd_arch_info ia64-elf64 > gdbarch_update: info.byte_order 1 (little) > gdbarch_update: info.osabi 5 (GNU/Linux) > gdbarch_update: info.abfd 0x0 > gdbarch_update: info.tdep_info 0x0 > gdbarch_update: Architecture 0x60000000000b2620 (ia64-elf64) unchanged ... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net