From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17446 invoked by alias); 18 Feb 2002 12:02:30 -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 17266 invoked from network); 18 Feb 2002 12:02:20 -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 12:02:20 -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 NAA29735 ; Mon, 18 Feb 2002 13:02:20 +0100 (MET) From: "Peter.Schauer" Received: (pes@localhost) by reisser.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) id NAA06278 ; Mon, 18 Feb 2002 13:02:19 +0100 (MET) Message-Id: <200202181202.NAA06278@reisser.regent.e-technik.tu-muenchen.de> Subject: Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ? To: Richard.Earnshaw@arm.com Date: Mon, 18 Feb 2002 04:02:00 -0000 Cc: gdb-patches@sources.redhat.com In-Reply-To: <200202181051.KAA02319@cam-mail2.cambridge.arm.com>; from "Richard Earnshaw" at Feb 18, 102 11:54 am X-Mailer: ELM [version 2.3 PL6] X-SW-Source: 2002-02/txt/msg00468.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. > > > > A couple of observations, which may be off base. > > 1) If you are running with a core file, the functionality of gdb is going > to be largely limited to examining data structures etc. I'm not aware > that gdb can step or call inferior functions etc once we've dumped core. > So it may be that a generic core description is adequate. In my particular case, I was thinking about tinkering with frame_chain_valid, which affected backtraces in core files. > 2) Where are your symbols coming from. It surely isn't the core file, so > it is probably the original image. If you have that somewhere then you > can determine its OS and ABI and use that to aid interpreting the core > file, right? If we should ever need it (although we should try hard to avoid it), this might be the right approach. Passing a `core file' flag to *gdbarch_init, and leaving *gdbarch_init the choice to not change the `os' if it is called from core_open. -- Peter Schauer pes@regent.e-technik.tu-muenchen.de