From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23335 invoked by alias); 29 Oct 2007 19:14:33 -0000 Received: (qmail 23316 invoked by uid 22791); 29 Oct 2007 19:14:32 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 19:13:31 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0A56898348; Mon, 29 Oct 2007 19:13:29 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id D509C98347; Mon, 29 Oct 2007 19:13:28 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1Ima3E-0003h8-52; Mon, 29 Oct 2007 15:13:28 -0400 Date: Mon, 29 Oct 2007 19:16:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] PowerPC ABI detection and overrides Message-ID: <20071029191328.GA13900@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20071029183229.GA10700@caradoc.them.org> <200710291859.l9TIx0k9006357@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710291859.l9TIx0k9006357@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00769.txt.bz2 On Mon, Oct 29, 2007 at 07:59:00PM +0100, Ulrich Weigand wrote: > Thinking about the problem I had at the time, maybe the real issue > is that those features detected from the BFD are not considered > as distinuishing factors when deciding whether to set up a new > gdbarch or return a cached one: > > /* Find a candidate among extant architectures. */ > for (arches = gdbarch_list_lookup_by_info (arches, &info); > arches != NULL; > arches = gdbarch_list_lookup_by_info (arches->next, &info)) > { > /* Word size in the various PowerPC bfd_arch_info structs isn't > meaningful, because 64-bit CPUs can run in 32-bit mode. So, perform > separate word size check. */ > tdep = gdbarch_tdep (arches->gdbarch); > if (tdep && tdep->wordsize == wordsize) > { > if (tdesc_data != NULL) > tdesc_data_cleanup (tdesc_data); > return arches->gdbarch; > } > } > > > Note that gdbarch_list_lookup_by_info ignores the info.abfd field. > This means that if you first looked up any PPC gdbarch without specifying > a BFD, and later on you look up a PPC gdbarch with BFD, you'll get that > first gdbarch returned from the cache, even though it doesn't actually > fit the current properties. Ignoring abfd is deliberate; we should be able to construct the same arch with or without a BFD. But ignoring things derived from abfd is a bug indeed. The MIPS target stashes ELF flags in its tdep structure for this reason. PowerPC may not need that heavyweight check, but it does need some other things, e.g., sysv_abi. Actually that's the only one that I see that ought to be checked. Maybe that will fix the bug? -- Daniel Jacobowitz CodeSourcery