From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1369 invoked by alias); 18 Feb 2002 10:52:08 -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 1256 invoked from network); 18 Feb 2002 10:52:07 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 18 Feb 2002 10:52:07 -0000 Received: by fw-cam.cambridge.arm.com; id KAA08914; Mon, 18 Feb 2002 10:52:05 GMT Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma008466; Mon, 18 Feb 02 10:51:46 GMT Received: from cam-mail2.cambridge.arm.com (localhost [127.0.0.1]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA11157; Mon, 18 Feb 2002 10:51:45 GMT Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id KAA02319; Mon, 18 Feb 2002 10:51:44 GMT Message-Id: <200202181051.KAA02319@cam-mail2.cambridge.arm.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Peter.Schauer" cc: drow@mvista.com (Daniel Jacobowitz), gdb-patches@sources.redhat.com, ac131313@cygnus.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ? In-reply-to: Your message of "Mon, 18 Feb 2002 09:44:45 +0700." <200202180844.JAA05757@reisser.regent.e-technik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Feb 2002 02:52:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-02/txt/msg00467.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. 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? R.