This is the mail archive of the
mailing list for the GDB project.
Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ?
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- To: Richard dot Earnshaw at arm dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 18 Feb 2002 13:02:19 MET
- Subject: Re: [RFD] How to fix FRAME_CHAIN_VALID redefinition in config/i386/tm-i386v4.h ?
> > 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 firstname.lastname@example.org