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

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

[Peter.Schauer]

Due to this change:

2002-02-10  Andrew Cagney  <ac131313@redhat.com>

        * gdbarch.sh: For for level one methods, disallow a definition
        when partially multi-arched.  Add comments explaining rationale.
        * gdbarch.h: Re-generate.

native SVR4 based platforms (including Solaris x86) no longer compile,
as they redefine FRAME_CHAIN_VALID in config/i386/tm-i386v4.h.

I understand, that this redefinition has to go, but I have no idea, how to
get back to the old behaviour cleanly.

Three approaches come to mind:

- Do nothing about it and let SVR4 based platforms backtrace through main.
  This is the simplest solution, albeit ugly.

- Use func_frame_chain_valid instead of file_frame_chain_valid in
  i386-tdep.c. This would stop backtraces through main on GNU/Linux. See also
  http://sources.redhat.com/ml/gdb/2002-02/msg00117.html

- Try to switch the frame_chain_valid method dynamically in i386_gdbarch_init,
  something like:

 if (os_ident != ELFOSABI_NONE)
   set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
 else
   set_gdbarch_frame_chain_valid (gdbarch, func_frame_chain_valid);

  This approach would work well for SVR4, but causes interesting problems
  on GNU/Linux. As core files have no ABI markers, we can't distinguish
  them, and we get different backtracing behaviour when debugging an
  executable (GNU/Linux ABI) or a core file (generic ELF ABI), so we
  simply can't do it.

  I suspect that we will hit this kind of multiarching problem more often
  in native setups, where we can't discern the native ABI flavour from the
  generic one (the various native sigtramp variants come to mind).
  Do we need a hook from XXX_gdbarch_init to some native code ?

Any ideas, suggestions ?

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

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

[Andrew Cagney]

> Due to this change:
> 
> 2002-02-10  Andrew Cagney  <ac131313@redhat.com>
> 
> * gdbarch.sh: For for level one methods, disallow a definition
>         when partially multi-arched.  Add comments explaining rationale.
>         * gdbarch.h: Re-generate.
> 
> native SVR4 based platforms (including Solaris x86) no longer compile,
> as they redefine FRAME_CHAIN_VALID in config/i386/tm-i386v4.h.
> 
> I understand, that this redefinition has to go, but I have no idea, how to
> get back to the old behaviour cleanly.

Appreciated!

> Any ideas, suggestions ?

To expand a little on the superficial problem.  A non-multi-arch compile 
has:

	#include tm.h
		might define FRAME_CHAIN_VALID
	#include gdbarch.h
		doesn't define FRAME_CHAIN_VALID
		(as not multi-arch)
	#include frame.h
		defines FRAME_CHAIN_VALID
		if not defined using some convoluted
		#ifdef logic.

In the partial multi-arch case it ends up with:

	#include tm.h
		might define FRAME_CHAIN_VALID
	#include gdbarch.h
		(re)defines FRAME_CHAIN_VALID
	#include frame.h
		gets ignored

The upshot is that FRAME_CHAIN_VALID's definition can silently change 
when the multi-arch switch is thrown.  The above change stops this by 
barfing things during the build :-/

Looking at frame.h, though, I think I've come across some good news. 
The logic reads:

#if !defined (FRAME_CHAIN_VALID)
#if !defined (FRAME_CHAIN_VALID_ALTERNATE)
#define FRAME_CHAIN_VALID(chain, thisframe) file_frame_chain_valid 
(chain, thisframe)
#else
/* Use the alternate method of avoiding running up off the end of the frame
    chain or following frames back into the startup code.  See the comments
    in objfiles.h. */
#define FRAME_CHAIN_VALID(chain, thisframe) func_frame_chain_valid 
(chain,thisframe)
#endif /* FRAME_CHAIN_VALID_ALTERNATE */
#endif /* FRAME_CHAIN_VALID */

greping through the code, FRAME_CHAIN_VALID_ALTERNATE appears to have 
quietly disappeared!  Can someone confirm this?  Assuming that is the 
case, the above can be reduced to:

#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 :-(

--

> Three approaches come to mind:
> 
> - Do nothing about it and let SVR4 based platforms backtrace through main.
>   This is the simplest solution, albeit ugly.

I'll immediatly apply the above.  It gets you back the old behavour.

> - Use func_frame_chain_valid instead of file_frame_chain_valid in
>   i386-tdep.c. This would stop backtraces through main on GNU/Linux. See also
>   http://sources.redhat.com/ml/gdb/2002-02/msg00117.html
> 
> - Try to switch the frame_chain_valid method dynamically in i386_gdbarch_init,
>   something like:
> 
>  if (os_ident != ELFOSABI_NONE)
>    set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
>  else
>    set_gdbarch_frame_chain_valid (gdbarch, func_frame_chain_valid);
> 
>   This approach would work well for SVR4, but causes interesting problems
>   on GNU/Linux. As core files have no ABI markers, we can't distinguish
>   them, and we get different backtracing behaviour when debugging an
>   executable (GNU/Linux ABI) or a core file (generic ELF ABI), so we
>   simply can't do it.
> 
>   I suspect that we will hit this kind of multiarching problem more often
>   in native setups, where we can't discern the native ABI flavour from the
>   generic one (the various native sigtramp variants come to mind).

Yes.

>   Do we need a hook from XXX_gdbarch_init to some native code ?

It isn't just a native problem.  Consider a solaris-X-arm-linux-gnu GDB 
debugging a remote target that includes threads, shared libraries and 
sigtramps.

The current gdbarch select mechanism is based on the ABI and ISA but not 
the ``OS''.  (Strictly speaking SHLIBS and SIGTRAPPS and ... can 
probably be classed ABI, GDB's architecture doesn't reflect this).

> Any ideas, suggestions ?

Not really.  I'm having enough fun pinning BFD down on the semantics of 
bfd_architecture and bfd_machine.

Several thoughts:

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

Andrew

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

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

Er, FRAME_CHAIN_VALID is a multi-arch method.

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

The situtation is very similar to COERCE_FLOAT_TO_DOUBLE.  The problem 
should be solved in a generic way.  However, until then each target gets 
to come up with a local solution.

Andrew

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

[Daniel Jacobowitz]

On Sun, Feb 17, 2002 at 11:57:00AM -0500, Andrew Cagney wrote:
> >
> >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.
> 
> Er, FRAME_CHAIN_VALID is a multi-arch method.

Right.  Delete that part of the sentence and look at the changing the
value for all targets bit :)

> >>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.
> 
> The situtation is very similar to COERCE_FLOAT_TO_DOUBLE.  The problem 
> should be solved in a generic way.  However, until then each target gets 
> to come up with a local solution.

Yep.  COERCE_FLOAT_TO_DOUBLE is also on my hitlist.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Peter.Schauer]

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

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

[Richard Earnshaw]

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

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

[Peter.Schauer]

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

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

[Richard Earnshaw]

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

Credit where it's due: I lifted the idea out of the rs6k tdep file.

R.

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

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Peter,

How does the attached look for the immediate problem?  You'll need to 
run gdbarch.sh and move the files into place.

I'm, to be honest, still testing it.

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3263 bytes --]

2002-02-17  Andrew Cagney  <ac131313@redhat.com>

	* gdbarch.sh (FRAME_CHAIN_VALID): Only require at level 2.
	Default to func_frame_chain_valid.
	* gdbarch.h, gdbarch.c: Re-generate.
	* frame.h (FRAME_CHAIN_VALID): Delete definition.

Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.8
diff -u -r1.8 frame.h
--- frame.h	2001/12/07 12:10:15	1.8
+++ frame.h	2002/02/17 17:17:04
@@ -152,9 +152,6 @@
    targets.  If FRAME_CHAIN_VALID returns zero it means that the given frame
    is the outermost one and has no caller.
 
-   If a particular target needs a different definition, then it can override
-   the definition here by providing one in the tm file.
-
    XXXX - both default and alternate frame_chain_valid functions are
    deprecated.  New code should use dummy frames and one of the
    generic functions. */
@@ -165,17 +162,6 @@
 extern int generic_file_frame_chain_valid (CORE_ADDR, struct frame_info *);
 extern int generic_func_frame_chain_valid (CORE_ADDR, struct frame_info *);
 extern void generic_save_dummy_frame_tos (CORE_ADDR sp);
-
-#if !defined (FRAME_CHAIN_VALID)
-#if !defined (FRAME_CHAIN_VALID_ALTERNATE)
-#define FRAME_CHAIN_VALID(chain, thisframe) file_frame_chain_valid (chain, thisframe)
-#else
-/* Use the alternate method of avoiding running up off the end of the frame
-   chain or following frames back into the startup code.  See the comments
-   in objfiles.h. */
-#define FRAME_CHAIN_VALID(chain, thisframe) func_frame_chain_valid (chain,thisframe)
-#endif /* FRAME_CHAIN_VALID_ALTERNATE */
-#endif /* FRAME_CHAIN_VALID */
 
 /* The stack frame that the user has specified for commands to act on.
    Note that one cannot assume this is the address of valid data.  */
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.116
diff -u -r1.116 gdbarch.sh
--- gdbarch.sh	2002/02/16 23:09:16	1.116
+++ gdbarch.sh	2002/02/17 17:17:05
@@ -545,8 +545,14 @@
 v:2:FRAME_ARGS_SKIP:CORE_ADDR:frame_args_skip::::0:-1
 f:2:FRAMELESS_FUNCTION_INVOCATION:int:frameless_function_invocation:struct frame_info *fi:fi:::generic_frameless_function_invocation_not::0
 f:2:FRAME_CHAIN:CORE_ADDR:frame_chain:struct frame_info *frame:frame::0:0
-# See comments on DUMMY_FRAME for why this is required at level 1.
-f:1:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe::0:0
+# Define a default FRAME_CHAIN_VALID, in the form that is suitable for
+# most targets.  If FRAME_CHAIN_VALID returns zero it means that the
+# given frame is the outermost one and has no caller.
+#
+# XXXX - both default and alternate frame_chain_valid functions are
+# deprecated.  New code should use dummy frames and one of the generic
+# functions.
+f:2:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe:::func_frame_chain_valid::0
 f:2:FRAME_SAVED_PC:CORE_ADDR:frame_saved_pc:struct frame_info *fi:fi::0:0
 f:2:FRAME_ARGS_ADDRESS:CORE_ADDR:frame_args_address:struct frame_info *fi:fi::0:0
 f:2:FRAME_LOCALS_ADDRESS:CORE_ADDR:frame_locals_address:struct frame_info *fi:fi::0:0

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

[Peter.Schauer]

That would work fine for me.

To be 100% backwards compatible, I think that the default should be
file_frame_chain_valid though.
We could change that to func_frame_chain_valid in another patch then.

Thank you very much,

> This is a multi-part message in MIME format.
> --------------030001060904050205060306
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Peter,
> 
> How does the attached look for the immediate problem?  You'll need to 
> run gdbarch.sh and move the files into place.
> 
> I'm, to be honest, still testing it.
> 
> Andrew
> 
> --------------030001060904050205060306
> Content-Type: text/plain;
>  name="diffs"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="diffs"
> 
> 2002-02-17  Andrew Cagney  <ac131313@redhat.com>
> 
> 	* gdbarch.sh (FRAME_CHAIN_VALID): Only require at level 2.
> 	Default to func_frame_chain_valid.
> 	* gdbarch.h, gdbarch.c: Re-generate.
> 	* frame.h (FRAME_CHAIN_VALID): Delete definition.
> 
> Index: frame.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/frame.h,v
> retrieving revision 1.8
> diff -u -r1.8 frame.h
> --- frame.h	2001/12/07 12:10:15	1.8
> +++ frame.h	2002/02/17 17:17:04
> @@ -152,9 +152,6 @@
>     targets.  If FRAME_CHAIN_VALID returns zero it means that the given frame
>     is the outermost one and has no caller.
>  
> -   If a particular target needs a different definition, then it can override
> -   the definition here by providing one in the tm file.
> -
>     XXXX - both default and alternate frame_chain_valid functions are
>     deprecated.  New code should use dummy frames and one of the
>     generic functions. */
> @@ -165,17 +162,6 @@
>  extern int generic_file_frame_chain_valid (CORE_ADDR, struct frame_info *);
>  extern int generic_func_frame_chain_valid (CORE_ADDR, struct frame_info *);
>  extern void generic_save_dummy_frame_tos (CORE_ADDR sp);
> -
> -#if !defined (FRAME_CHAIN_VALID)
> -#if !defined (FRAME_CHAIN_VALID_ALTERNATE)
> -#define FRAME_CHAIN_VALID(chain, thisframe) file_frame_chain_valid (chain, thisframe)
> -#else
> -/* Use the alternate method of avoiding running up off the end of the frame
> -   chain or following frames back into the startup code.  See the comments
> -   in objfiles.h. */
> -#define FRAME_CHAIN_VALID(chain, thisframe) func_frame_chain_valid (chain,thisframe)
> -#endif /* FRAME_CHAIN_VALID_ALTERNATE */
> -#endif /* FRAME_CHAIN_VALID */
>  
>  /* The stack frame that the user has specified for commands to act on.
>     Note that one cannot assume this is the address of valid data.  */
> Index: gdbarch.sh
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbarch.sh,v
> retrieving revision 1.116
> diff -u -r1.116 gdbarch.sh
> --- gdbarch.sh	2002/02/16 23:09:16	1.116
> +++ gdbarch.sh	2002/02/17 17:17:05
> @@ -545,8 +545,14 @@
>  v:2:FRAME_ARGS_SKIP:CORE_ADDR:frame_args_skip::::0:-1
>  f:2:FRAMELESS_FUNCTION_INVOCATION:int:frameless_function_invocation:struct frame_info *fi:fi:::generic_frameless_function_invocation_not::0
>  f:2:FRAME_CHAIN:CORE_ADDR:frame_chain:struct frame_info *frame:frame::0:0
> -# See comments on DUMMY_FRAME for why this is required at level 1.
> -f:1:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe::0:0
> +# Define a default FRAME_CHAIN_VALID, in the form that is suitable for
> +# most targets.  If FRAME_CHAIN_VALID returns zero it means that the
> +# given frame is the outermost one and has no caller.
> +#
> +# XXXX - both default and alternate frame_chain_valid functions are
> +# deprecated.  New code should use dummy frames and one of the generic
> +# functions.
> +f:2:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe:::func_frame_chain_valid::0
>  f:2:FRAME_SAVED_PC:CORE_ADDR:frame_saved_pc:struct frame_info *fi:fi::0:0
>  f:2:FRAME_ARGS_ADDRESS:CORE_ADDR:frame_args_address:struct frame_info *fi:fi::0:0
>  f:2:FRAME_LOCALS_ADDRESS:CORE_ADDR:frame_locals_address:struct frame_info *fi:fi::0:0
> 
> --------------030001060904050205060306--
> 
> 
> 


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

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

[Andrew Cagney]

> That would work fine for me.

Thanks!

> To be 100% backwards compatible, I think that the default should be
> file_frame_chain_valid though.
> We could change that to func_frame_chain_valid in another patch then.

That is DanielJ's contention.  Leave it as a separate change (I'll 
create a bug report for that - I've got the GDB branch nerves).

Andrew

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

[Andrew Cagney]

> 2002-02-17  Andrew Cagney  <ac131313@redhat.com>
> 
> * gdbarch.sh (FRAME_CHAIN_VALID): Only require at level 2.
> 	Default to func_frame_chain_valid.
> 	* gdbarch.h, gdbarch.c: Re-generate.
> 	* frame.h (FRAME_CHAIN_VALID): Delete definition.
> 
> 
I've checked this in.

Andrew