From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25196 invoked by alias); 17 Feb 2002 13:45:31 -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 25056 invoked from network); 17 Feb 2002 13:45:26 -0000 Received: from unknown (HELO rennsau.regent.e-technik.tu-muenchen.de) (129.187.231.63) by sources.redhat.com with SMTP; 17 Feb 2002 13:45:26 -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 OAA22440 for ; Sun, 17 Feb 2002 14:45:25 +0100 (MET) From: "Peter.Schauer" Received: (pes@localhost) by reisser.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) id OAA04571 for gdb-patches@sources.redhat.com ; Sun, 17 Feb 2002 14:45:25 +0100 (MET) Message-Id: <200202171345.OAA04571@reisser.regent.e-technik.tu-muenchen.de> Subject: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ? To: gdb-patches@sources.redhat.com Date: Sun, 17 Feb 2002 05:45:00 -0000 X-Mailer: ELM [version 2.3 PL6] X-SW-Source: 2002-02/txt/msg00452.txt.bz2 Due to this change: 2002-02-10 Andrew Cagney * gdbarch.sh: For for level one methods, disallow a definition when partially multi-arched. Add comments explaining rationale. * gdbarch.h: Re-generate. native SVR4 based platforms (including Solaris x86) no longer compile, as they redefine FRAME_CHAIN_VALID in config/i386/tm-i386v4.h. I understand, that this redefinition has to go, but I have no idea, how to get back to the old behaviour cleanly. Three approaches come to mind: - Do nothing about it and let SVR4 based platforms backtrace through main. This is the simplest solution, albeit ugly. - Use func_frame_chain_valid instead of file_frame_chain_valid in i386-tdep.c. This would stop backtraces through main on GNU/Linux. See also http://sources.redhat.com/ml/gdb/2002-02/msg00117.html - Try to switch the frame_chain_valid method dynamically in i386_gdbarch_init, something like: if (os_ident != ELFOSABI_NONE) set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid); else set_gdbarch_frame_chain_valid (gdbarch, func_frame_chain_valid); This approach would work well for SVR4, but causes interesting problems on GNU/Linux. As core files have no ABI markers, we can't distinguish them, and we get different backtracing behaviour when debugging an executable (GNU/Linux ABI) or a core file (generic ELF ABI), so we simply can't do it. I suspect that we will hit this kind of multiarching problem more often in native setups, where we can't discern the native ABI flavour from the generic one (the various native sigtramp variants come to mind). Do we need a hook from XXX_gdbarch_init to some native code ? Any ideas, suggestions ? -- Peter Schauer pes@regent.e-technik.tu-muenchen.de