This is the mail archive of the
mailing list for the GDB project.
[RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ?
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- To: gdb-patches at sources dot redhat dot com
- Date: Sun, 17 Feb 2002 14:45:24 MET
- Subject: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ?
Due to this change:
2002-02-10 Andrew Cagney <firstname.lastname@example.org>
* 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
- Try to switch the frame_chain_valid method dynamically in i386_gdbarch_init,
if (os_ident != ELFOSABI_NONE)
set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
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 email@example.com