From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15340 invoked by alias); 5 Nov 2003 20:39:07 -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 15333 invoked from network); 5 Nov 2003 20:39:06 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 5 Nov 2003 20:39:06 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 72EF2800412; Wed, 5 Nov 2003 15:39:06 -0500 (EST) Message-ID: <3FA95FEA.4090201@redhat.com> Date: Wed, 05 Nov 2003 20:39:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar Cc: kettenis@gnu.org, gdb@sources.redhat.com Subject: Re: Problem with deprecated_select_gdbarch_hack References: <3FA6EC40.8060007@redhat.com> <20031104003735.GA84210@dhcp01.pn.xcllnt.net> In-Reply-To: <20031104003735.GA84210@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00039.txt.bz2 Marcel Moolenaar wrote: > 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. > I have recently checked in a change to the ia64-tdep.c code to modernize it to grab the osabi from the gdbarch_info parameter and to call gdbarch_list_lookup_by_info() to look for existing gdbarch candidates. This fixes the problem without having to remove the assertion. Perhaps leaving the assertion will point out any existing platforms that use the older code ia64 was formerly using. -- Jeff J. > ... > >>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 > > ... >