From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17129 invoked by alias); 17 Feb 2002 16:37:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17045 invoked from network); 17 Feb 2002 16:37:04 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 17 Feb 2002 16:37:04 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16cUG5-0000s7-00; Sun, 17 Feb 2002 11:33:49 -0500 Date: Sun, 17 Feb 2002 08:37:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: "Peter.Schauer" , gdb-patches@sources.redhat.com Subject: Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ? Message-ID: <20020217113349.A3217@nevyn.them.org> Mail-Followup-To: Andrew Cagney , "Peter.Schauer" , gdb-patches@sources.redhat.com References: <200202171345.OAA04571@reisser.regent.e-technik.tu-muenchen.de> <3C6FD90E.5000504@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6FD90E.5000504@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00454.txt.bz2 On Sun, Feb 17, 2002 at 11:23:42AM -0500, Andrew Cagney wrote: > #ifndef FRAME_CHAIN_VALID > #define FRAME_CHAIN_VALID(chain, thisframe) file_frame_chain_valid > (chain, thisframe) > > and that, in turn, can be moved to gdbarch.* allowing the level-1 > requirement to be dropped. Doesn't fix the underlying problem though :-( Or we could fix this particular problem by making FRAME_CHAIN_VALID into a multi-arch method (just in case, and for hppa (?) which seemed to have a useful redefinition, though I don't see why it was needed), defaulting it to func_frame_chain_valid for all targets. No one ever gave me a reason not to do this when I asked. > - allow multiple registrarations for an architecture (eg i386-tdep.c, > i386-linux-tdep.c, ...) and have gdbarch try the OS specific one before > the generic one. > > - Let a tdep file specify the ``os'' when registering their architecture > so that the gdbarch code can select based on that. > > - Add an ``os'' field to ``struct gdbarch_info'' which can be set to > what is known to be the OS. > > - Just tweek i386-tdep.c's *gdbarch_init() so that it uses a better > local (architecture specific) heuristic. > > I suspect a combination of the first three is the best. The moment the > heuristic is pushed down to the target we end up with inconsistent, > target dependant, behavour. There's some interesting code along these lines in what Richard committed for ARM. He parses things like glibc's .note.ABI-tag section, as well as ELF_OSABI fields where set. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer