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

[Daniel Jacobowitz <drow at mvista dot com>]

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