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

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

> > 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