From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12456 invoked by alias); 16 Jun 2003 21:57:01 -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 12442 invoked from network); 16 Jun 2003 21:57:01 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 16 Jun 2003 21:57:01 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19S1yg-0003k6-00; Mon, 16 Jun 2003 16:57:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19S1xm-0003Ku-00; Mon, 16 Jun 2003 17:56:30 -0400 Date: Mon, 16 Jun 2003 21:57:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: "Gdb@Sources.Redhat.Com" , Mark Kettenis Subject: Re: found gdbarch solib issue Message-ID: <20030616215630.GB12729@nevyn.them.org> Mail-Followup-To: Kris Warkentin , "Gdb@Sources.Redhat.Com" , Mark Kettenis References: <074f01c33447$d404c2b0$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <074f01c33447$d404c2b0$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00326.txt.bz2 On Mon, Jun 16, 2003 at 04:42:39PM -0400, Kris Warkentin wrote: > So I was tracing around trying to figure out why my > sysv_fetch_link_map_offsets function was getting lost when architectures > were changing. I noticed that _init_abi was being called which then > calls my nto_init_abi through gdbarch_init_osabi(). > > Problem was, at some point we're changing arches for some reason, whether > setting it from a file or whatever, and the generic init_abi is called > again. This time, however, my handler for nto_init_abi isn't called. > > The change that makes this problem go away is below but I'm not entirely > confident that it's the right thing to do. If you look at the 'compatible' > function, ie. mips_compatible, all it's doing is comparing arches. The > original test below is comparing pointers which I think might not be right. > Either way, if I do this change, all my worries fly away. > > Any reason anyone can think of why this might be bad? Shouldn't it be returning arch_info anyway? Why isn't it? Is it returning handler->arch_info? > - compatible = arch_info->compatible (arch_info, handler->arch_info); > - if (compatible == handler->arch_info) > + if(arch_info->compatible (arch_info, handler->arch_info)) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer