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.

Many thanks for your explanations and feedback,

> On Sun, Feb 17, 2002 at 11:23:42AM -0500, Andrew Cagney wrote:
> > #ifndef FRAME_CHAIN_VALID
> > #define FRAME_CHAIN_VALID(chain, thisframe) file_frame_chain_valid 
> > (chain, thisframe)
> > 
> > and that, in turn, can be moved to gdbarch.* allowing the level-1 
> > requirement to be dropped.  Doesn't fix the underlying problem though :-(
> 
> Or we could fix this particular problem by making FRAME_CHAIN_VALID
> into a multi-arch method (just in case, and for hppa (?) which seemed
> to have a useful redefinition, though I don't see why it was needed),
> defaulting it to func_frame_chain_valid for all targets.  No one ever
> gave me a reason not to do this when I asked.
> 
> > - allow multiple registrarations for an architecture (eg i386-tdep.c, 
> > i386-linux-tdep.c, ...) and have gdbarch try the OS specific one before 
> > the generic one.
> > 
> > - Let a tdep file specify the ``os'' when registering their architecture 
> > so that the gdbarch code can select based on that.
> > 
> > - Add an ``os'' field to ``struct gdbarch_info'' which can be set to 
> > what is known to be the OS.
> > 
> > - Just tweek i386-tdep.c's *gdbarch_init() so that it uses a better 
> > local (architecture specific) heuristic.
> > 
> > I suspect a combination of the first three is the best.  The moment the 
> > heuristic is pushed down to the target we end up with inconsistent, 
> > target dependant, behavour.
> 
> There's some interesting code along these lines in what Richard
> committed for ARM.  He parses things like glibc's .note.ABI-tag
> section, as well as ELF_OSABI fields where set.
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de