[RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ?

["Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>]

Due to this change:

2002-02-10  Andrew Cagney  <ac131313@redhat.com>

        * 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