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

[Richard Earnshaw <rearnsha@arm.com>]

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

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?

R.