From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23925 invoked by alias); 18 Feb 2002 08:44:54 -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 23736 invoked from network); 18 Feb 2002 08:44:50 -0000 Received: from unknown (HELO rennsau.regent.e-technik.tu-muenchen.de) (129.187.231.63) by sources.redhat.com with SMTP; 18 Feb 2002 08:44:50 -0000 Received: from reisser.regent.e-technik.tu-muenchen.de (reisser.regent.e-technik.tu-muenchen.de [129.187.231.143]) by rennsau.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) with ESMTP id JAA28043 ; Mon, 18 Feb 2002 09:44:46 +0100 (MET) From: "Peter.Schauer" Received: (pes@localhost) by reisser.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) id JAA05757 ; Mon, 18 Feb 2002 09:44:45 +0100 (MET) Message-Id: <200202180844.JAA05757@reisser.regent.e-technik.tu-muenchen.de> Subject: Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ? To: drow@mvista.com (Daniel Jacobowitz) Date: Mon, 18 Feb 2002 00:44:00 -0000 Cc: gdb-patches@sources.redhat.com, ac131313@cygnus.com In-Reply-To: <20020217113349.A3217@nevyn.them.org>; from "Daniel Jacobowitz" at Feb 17, 102 9:01 pm X-Mailer: ELM [version 2.3 PL6] X-SW-Source: 2002-02/txt/msg00465.txt.bz2 I did have a look at Richard's code, but *gdbarch_init() depends on the things passed in via `struct gdbarch_info'. gdbarch_tdep_info seemed promising, but is currently unused, so it seems that in the current framework we have to deduce everything from a BFD. However, in my particular case, you can't tell a GNU/Linux core file from a generic ELF core file (there are no .note.ABI-tag sections in a core file). Even if we add an `os' field to `struct gdbarch_info', we would have to pass the os information down all the way from core_open -> set_gdbarch_from_file. And even then we can't tell the current `os' for the core file in core_open. It seems that we have to avoid any additional OS dependency for core files in the gdbarch vector, although having gdbarch try the OS specific one before the generic one might be feasible. The immediate problem would be fixed by requiring FRAME_CHAIN_VALID only at multi-arch level 2. Many thanks for your explanations and feedback, > 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 > > -- Peter Schauer pes@regent.e-technik.tu-muenchen.de