RFA: Recognize bottom of stack on Linux

RFA: Recognize bottom of stack on Linux

[Jim Blandy]

Now, some folks feel that GDB should show the whole stack, including
_start, __libc_start_main, and anything else that's there.  However,
this isn't the way GDB has ever traditionally behaved on native
targets.  So this patch makes GDB's backtraces end after main.

2002-02-03  Jim Blandy  <jimb@redhat.com>

	* i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain
	after `main', not just after the compilation unit containing the
	entry point.

Index: gdb/i386-linux-tdep.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/i386-linux-tdep.c,v
retrieving revision 2.7.10.1
diff -c -r2.7.10.1 i386-linux-tdep.c
*** gdb/i386-linux-tdep.c	2002/01/11 22:08:41	2.7.10.1
--- gdb/i386-linux-tdep.c	2002/02/04 02:19:28
***************
*** 352,358 ****
    if (frame->signal_handler_caller || FRAMELESS_SIGNAL (frame))
      return frame->frame;
  
!   if (! inside_entry_file (frame->pc))
      return read_memory_unsigned_integer (frame->frame, 4);
  
    return 0;
--- 352,364 ----
    if (frame->signal_handler_caller || FRAMELESS_SIGNAL (frame))
      return frame->frame;
  
!   /* On Linux, the entry point is called _start, but that invokes
!      something called __libc_start_main, which calls main.  So if we
!      want the stack to end at main (as it does for GDB's other
!      targets), the `PC in compilation unit containing entry point'
!      rule triggers too late to get us the right result.  */
!   if (! inside_entry_file (frame->pc)
!       && ! inside_main_func (frame->pc))
      return read_memory_unsigned_integer (frame->frame, 4);
  
    return 0;

Re: RFA: Recognize bottom of stack on Linux

[Daniel Jacobowitz]

On Sun, Feb 03, 2002 at 09:06:36PM -0500, Jim Blandy wrote:
> 
> Now, some folks feel that GDB should show the whole stack, including
> _start, __libc_start_main, and anything else that's there.  However,
> this isn't the way GDB has ever traditionally behaved on native
> targets.  So this patch makes GDB's backtraces end after main.
> 
> 2002-02-03  Jim Blandy  <jimb@redhat.com>
> 
> 	* i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain
> 	after `main', not just after the compilation unit containing the
> 	entry point.

Shouldn't we use func_frame_chain_valid instead of
file_frame_chain_valid instead of duplicating this?

I don't understand why that function doesn't have more callers.  It
seems that at least all non-embedded targets, or at the very least all
Linux targets, should use it.

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

Re: RFA: Recognize bottom of stack on Linux

[Eli Zaretskii]

On Sun, 3 Feb 2002, Jim Blandy wrote:

> Now, some folks feel that GDB should show the whole stack, including
> _start, __libc_start_main, and anything else that's there.  However,
> this isn't the way GDB has ever traditionally behaved on native
> targets.  So this patch makes GDB's backtraces end after main.

I'm probably missing something important, but couldn't there be a program 
written in assembly that doesn't have a `main' at all?

Re: RFA: Recognize bottom of stack on Linux

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Sun, Feb 03, 2002 at 09:06:36PM -0500, Jim Blandy wrote:
> >
> > Now, some folks feel that GDB should show the whole stack, including
> > _start, __libc_start_main, and anything else that's there.  However,
> > this isn't the way GDB has ever traditionally behaved on native
> > targets.  So this patch makes GDB's backtraces end after main.
> >
> > 2002-02-03  Jim Blandy  <jimb@redhat.com>
> >
> >       * i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain
> >       after `main', not just after the compilation unit containing the
> >       entry point.
> 
> Shouldn't we use func_frame_chain_valid instead of
> file_frame_chain_valid instead of duplicating this?
> 
> I don't understand why that function doesn't have more callers.  It
> seems that at least all non-embedded targets, or at the very least all
> Linux targets, should use it.

It doesn't always work as advertised...

Re: RFA: Recognize bottom of stack on Linux

[Kevin Buettner]

On Feb 3,  9:06pm, Jim Blandy wrote:

> Now, some folks feel that GDB should show the whole stack, including
> _start, __libc_start_main, and anything else that's there.  However,
> this isn't the way GDB has ever traditionally behaved on native
> targets.  So this patch makes GDB's backtraces end after main.

What's the reason for this change?  I think it'd be better for GDB
to show as much of the stack as possible regardless of tradition.

Kevin

Re: RFA: Recognize bottom of stack on Linux

[Andrew Cagney]

> On Feb 3,  9:06pm, Jim Blandy wrote:
> 
> 
>> Now, some folks feel that GDB should show the whole stack, including
>> _start, __libc_start_main, and anything else that's there.  However,
>> this isn't the way GDB has ever traditionally behaved on native
>> targets.  So this patch makes GDB's backtraces end after main.
> 
> 
> What's the reason for this change?  I think it'd be better for GDB
> to show as much of the stack as possible regardless of tradition.


One reason that comes to mind is that what appears below main is 
starting to get a little out of control.  In the good old days, nothing 
appeared below main because there was simply nothing there.  The may not 
have even had an entry point since crt0.o always came first.  Now, well ...

Perhaphs the correct fix is to let the user decide.  Add a ``set 
stack-bottom-strategy ....''  :-)

Andrew

Re: RFA: Recognize bottom of stack on Linux

[Kevin Buettner]

On Feb 4,  8:32pm, Andrew Cagney wrote:

[Regarding what, if anything, to show of the frames below main() in a
backtrace...]
> Perhaphs the correct fix is to let the user decide.  Add a ``set 
> stack-bottom-strategy ....''  :-)

I think that may be best.  I don't usually want to look at what's
below main(), but when I do, it's usually pretty important to me...

Re: RFA: Recognize bottom of stack on Linux

[Daniel Jacobowitz]

On Mon, Feb 04, 2002 at 06:41:10PM -0700, Kevin Buettner wrote:
> On Feb 4,  8:32pm, Andrew Cagney wrote:
> 
> [Regarding what, if anything, to show of the frames below main() in a
> backtrace...]
> > Perhaphs the correct fix is to let the user decide.  Add a ``set 
> > stack-bottom-strategy ....''  :-)
> 
> I think that may be best.  I don't usually want to look at what's
> below main(), but when I do, it's usually pretty important to me...

Set backtrace-below-main perhaps?

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

Re: RFA: Recognize bottom of stack on Linux

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Mon, Feb 04, 2002 at 06:41:10PM -0700, Kevin Buettner wrote:
> > On Feb 4,  8:32pm, Andrew Cagney wrote:
> >
> > [Regarding what, if anything, to show of the frames below main() in a
> > backtrace...]
> > > Perhaphs the correct fix is to let the user decide.  Add a ``set
> > > stack-bottom-strategy ....''  :-)
> >
> > I think that may be best.  I don't usually want to look at what's
> > below main(), but when I do, it's usually pretty important to me...
> 
> Set backtrace-below-main perhaps?

Don't forget about threads -- their backtrace does not contain main at
all.

Re: RFA: Recognize bottom of stack on Linux

[Daniel Jacobowitz]

On Mon, Feb 04, 2002 at 05:49:46PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Mon, Feb 04, 2002 at 06:41:10PM -0700, Kevin Buettner wrote:
> > > On Feb 4,  8:32pm, Andrew Cagney wrote:
> > >
> > > [Regarding what, if anything, to show of the frames below main() in a
> > > backtrace...]
> > > > Perhaphs the correct fix is to let the user decide.  Add a ``set
> > > > stack-bottom-strategy ....''  :-)
> > >
> > > I think that may be best.  I don't usually want to look at what's
> > > below main(), but when I do, it's usually pretty important to me...
> > 
> > Set backtrace-below-main perhaps?
> 
> Don't forget about threads -- their backtrace does not contain main at
> all.

Should not matter.  The backtrace only stops when it detects main(), or
_start, or a PC of 0; I believe the PC of 0 check is what picks up
threads.

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

Re: RFA: Recognize bottom of stack on Linux

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Feb 04, 2002 at 06:41:10PM -0700, Kevin Buettner wrote:
> > On Feb 4,  8:32pm, Andrew Cagney wrote:
> > 
> > [Regarding what, if anything, to show of the frames below main() in a
> > backtrace...]
> > > Perhaphs the correct fix is to let the user decide.  Add a ``set 
> > > stack-bottom-strategy ....''  :-)
> > 
> > I think that may be best.  I don't usually want to look at what's
> > below main(), but when I do, it's usually pretty important to me...
> 
> Set backtrace-below-main perhaps?

I don't disagree, but I think it's a fix independent of my change.

I think the default should be to conceal stuff below main, since most
users aren't debugging their system startup code.  Keep in mind that
this group has a skewed perspective on that, since that's exactly the
kind of thing we *do* spend our time worrying about.

Re: RFA: Recognize bottom of stack on Linux

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Sun, Feb 03, 2002 at 09:06:36PM -0500, Jim Blandy wrote:
> > 
> > Now, some folks feel that GDB should show the whole stack, including
> > _start, __libc_start_main, and anything else that's there.  However,
> > this isn't the way GDB has ever traditionally behaved on native
> > targets.  So this patch makes GDB's backtraces end after main.
> > 
> > 2002-02-03  Jim Blandy  <jimb@redhat.com>
> > 
> > 	* i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain
> > 	after `main', not just after the compilation unit containing the
> > 	entry point.
> 
> Shouldn't we use func_frame_chain_valid instead of
> file_frame_chain_valid instead of duplicating this?
> 
> I don't understand why that function doesn't have more callers.  It
> seems that at least all non-embedded targets, or at the very least all
> Linux targets, should use it.

The following works fine for me, too:

2002-02-05  Jim Blandy  <jimb@redhat.com>

	* i386-linux-tdep.c (i386_linux_frame_chain): Use
	func_frame_chain_valid, instead of plain inside_entry_file.

Index: gdb/i386-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.10
diff -c -r1.10 i386-linux-tdep.c
*** gdb/i386-linux-tdep.c	2001/12/10 22:04:10	1.10
--- gdb/i386-linux-tdep.c	2002/02/05 19:55:03
***************
*** 342,348 ****
    if (frame->signal_handler_caller || FRAMELESS_SIGNAL (frame))
      return frame->frame;
  
!   if (! inside_entry_file (frame->pc))
      return read_memory_unsigned_integer (frame->frame, 4);
  
    return 0;
--- 342,356 ----
    if (frame->signal_handler_caller || FRAMELESS_SIGNAL (frame))
      return frame->frame;
  
!   /* On Linux, the entry point is called _start, but that invokes
!      something called __libc_start_main, which calls main.  So if we
!      want the stack to end at main (as it does for GDB's other
!      targets), the `PC in entry point function' rule triggers too late
!      to get us the right result; we've already included
!      __libc_start_main in the backtrace, which we don't want.
!      func_frame_chain_valid checks both for `main', and for the entry
!      point function.  */
!   if (func_frame_chain_valid (1, frame))
      return read_memory_unsigned_integer (frame->frame, 4);
  
    return 0;

Re: RFA: Recognize bottom of stack on Linux

[Daniel Jacobowitz]

On Tue, Feb 05, 2002 at 02:59:39PM -0500, Jim Blandy wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Sun, Feb 03, 2002 at 09:06:36PM -0500, Jim Blandy wrote:
> > > 
> > > Now, some folks feel that GDB should show the whole stack, including
> > > _start, __libc_start_main, and anything else that's there.  However,
> > > this isn't the way GDB has ever traditionally behaved on native
> > > targets.  So this patch makes GDB's backtraces end after main.
> > > 
> > > 2002-02-03  Jim Blandy  <jimb@redhat.com>
> > > 
> > > 	* i386-linux-tdep.c (i386_linux_frame_chain): Stop the frame chain
> > > 	after `main', not just after the compilation unit containing the
> > > 	entry point.
> > 
> > Shouldn't we use func_frame_chain_valid instead of
> > file_frame_chain_valid instead of duplicating this?
> > 
> > I don't understand why that function doesn't have more callers.  It
> > seems that at least all non-embedded targets, or at the very least all
> > Linux targets, should use it.
> 
> The following works fine for me, too:
> 
> 2002-02-05  Jim Blandy  <jimb@redhat.com>
> 
> 	* i386-linux-tdep.c (i386_linux_frame_chain): Use
> 	func_frame_chain_valid, instead of plain inside_entry_file.

I like this.  The way func_frame_chain_valid should really be used is
by something like:

  /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
  set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);

(copied from i386-tdep.c).

Does this patch work for you?

I'm curious as to why we can't just set this universally, or at least a
little more globally.  Most things that have a main () use it as a
normal main ().  I'd propose that we set it as the default frame chain,
and provide/document an option to ignore inside_main_func.


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


Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.50
diff -u -r1.50 i386-tdep.c
--- i386-tdep.c	2002/01/01 16:29:43	1.50
+++ i386-tdep.c	2002/02/05 21:47:11
@@ -1324,7 +1324,7 @@
 
   set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack);
 
-  /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
+  /* NOTE: tm-i386nw.h, tm-i386v4.h, and tm-linux.h override this.  */
   set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
 
   /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h,
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.16
diff -u -r1.16 tm-linux.h
--- config/i386/tm-linux.h	2001/11/08 00:03:52	1.16
+++ config/i386/tm-linux.h	2002/02/05 21:47:11
@@ -31,6 +31,10 @@
 #include "i386/tm-i386.h"
 #include "tm-linux.h"
 
+/* Use the alternate method of determining valid frame chains. */
+
+#define FRAME_CHAIN_VALID(fp,fi) func_frame_chain_valid (fp, fi)
+
 /* Register number for the "orig_eax" pseudo-register.  If this
    pseudo-register contains a value >= 0 it is interpreted as the
    system call number that the kernel is supposed to restart.  */

Re: RFA: Recognize bottom of stack on Linux

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> I like this.  The way func_frame_chain_valid should really be used is
> by something like:
> 
>   /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
>   set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
> 
> (copied from i386-tdep.c).
> 
> Does this patch work for you?

Yes, thanks.  I've included a revised version of my patch below.

> I'm curious as to why we can't just set this universally, or at least a
> little more globally.  Most things that have a main () use it as a
> normal main ().  I'd propose that we set it as the default frame chain,
> and provide/document an option to ignore inside_main_func.

Well, gdbarch is never supposed to change the default behavior of
macros; this helps us convert pre-gdbarch targets incrementally.
Simply turning on gdbarch for one's target ideally wouldn't change its
behavior at all.


2002-02-06  Jim Blandy  <jimb@redhat.com>

	Fix from Daniel Jacobowitz:
	* config/i386/tm-linux.h (FRAME_CHAIN_VALID): Use
	`func_frame_chain_valid' for this.
	* i386-tdep.c (i386_gdbarch_init): Note that tm-linux.h is
	overriding the selection we make here.

Index: gdb/i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.50
diff -c -r1.50 i386-tdep.c
*** gdb/i386-tdep.c	2002/01/01 16:29:43	1.50
--- gdb/i386-tdep.c	2002/02/06 19:19:27
***************
*** 1324,1330 ****
  
    set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack);
  
!   /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
    set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
  
    /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h,
--- 1324,1330 ----
  
    set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack);
  
!   /* NOTE: tm-i386nw.h, tm-i386v4.h, and tm-linux.h override this.  */
    set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
  
    /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h,
Index: gdb/config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.16
diff -c -r1.16 tm-linux.h
*** gdb/config/i386/tm-linux.h	2001/11/08 00:03:52	1.16
--- gdb/config/i386/tm-linux.h	2002/02/06 19:19:28
***************
*** 82,87 ****
--- 82,98 ----
  #define IN_SIGTRAMP(pc, name) i386_linux_in_sigtramp (pc, name)
  extern int i386_linux_in_sigtramp (CORE_ADDR, char *);
  
+ /* On Linux, the entry point is called _start, but that invokes
+    something called __libc_start_main, which calls main.  So if we
+    want the stack to end at main (as it does for most GDB targets),
+    it's not enough for us to use inside_entry_func or
+    inside_entry_file; that rule will only trigger after we've included
+    __libc_start_main in the backtrace, which we don't want.
+    func_frame_chain_valid checks both for `main', and for the entry
+    point function.  */
+ /* Use the alternate method of determining valid frame chains. */
+ #define FRAME_CHAIN_VALID(fp,fi) func_frame_chain_valid (fp, fi)
+ 
  #undef FRAME_CHAIN
  #define FRAME_CHAIN(frame) i386_linux_frame_chain (frame)
  extern CORE_ADDR i386_linux_frame_chain (struct frame_info *frame);

Re: RFA: Recognize bottom of stack on Linux

[Andrew Cagney]

> Set backtrace-below-main perhaps?
> 
> 
> I don't disagree, but I think it's a fix independent of my change.


Just file a change-request on that one.

Andrew

Re: RFA: Recognize bottom of stack on Linux

[Andrew Cagney]

> I'm curious as to why we can't just set this universally, or at least a
>> little more globally.  Most things that have a main () use it as a
>> normal main ().  I'd propose that we set it as the default frame chain,
>> and provide/document an option to ignore inside_main_func.
> 
> 
> Well, gdbarch is never supposed to change the default behavior of
> macros; this helps us convert pre-gdbarch targets incrementally.
> Simply turning on gdbarch for one's target ideally wouldn't change its
> behavior at all.


Yes, definitly.  Rule of least suprise, learnt from multi-arch experience.

However, that doesn't stop an independant change that does alter the 
default behavour.  cf. my proposed patch to change the default value of 
TARGET_LONG_DOUBLE_FORMAT to ieee_double from floatformat_unknown.

enjoy,
Andrew

Re: RFA: Recognize bottom of stack on Linux

[Daniel Jacobowitz]

On Wed, Feb 06, 2002 at 02:26:00PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I like this.  The way func_frame_chain_valid should really be used is
> > by something like:
> > 
> >   /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
> >   set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
> > 
> > (copied from i386-tdep.c).
> > 
> > Does this patch work for you?
> 
> Yes, thanks.  I've included a revised version of my patch below.
> 
> > I'm curious as to why we can't just set this universally, or at least a
> > little more globally.  Most things that have a main () use it as a
> > normal main ().  I'd propose that we set it as the default frame chain,
> > and provide/document an option to ignore inside_main_func.
> 
> Well, gdbarch is never supposed to change the default behavior of
> macros; this helps us convert pre-gdbarch targets incrementally.
> Simply turning on gdbarch for one's target ideally wouldn't change its
> behavior at all.

Ping - this patch seems to have fallen through the cracks.  It fixes
eight of the twenty remaining testsuite failures on my configuration,
so I'd like to see it committed.

> 
> 
> 2002-02-06  Jim Blandy  <jimb@redhat.com>
> 
> 	Fix from Daniel Jacobowitz:
> 	* config/i386/tm-linux.h (FRAME_CHAIN_VALID): Use
> 	`func_frame_chain_valid' for this.
> 	* i386-tdep.c (i386_gdbarch_init): Note that tm-linux.h is
> 	overriding the selection we make here.
> 
> Index: gdb/i386-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-tdep.c,v
> retrieving revision 1.50
> diff -c -r1.50 i386-tdep.c
> *** gdb/i386-tdep.c	2002/01/01 16:29:43	1.50
> --- gdb/i386-tdep.c	2002/02/06 19:19:27
> ***************
> *** 1324,1330 ****
>   
>     set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack);
>   
> !   /* NOTE: tm-i386nw.h and tm-i386v4.h override this.  */
>     set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
>   
>     /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h,
> --- 1324,1330 ----
>   
>     set_gdbarch_pc_in_call_dummy (gdbarch, pc_in_call_dummy_on_stack);
>   
> !   /* NOTE: tm-i386nw.h, tm-i386v4.h, and tm-linux.h override this.  */
>     set_gdbarch_frame_chain_valid (gdbarch, file_frame_chain_valid);
>   
>     /* NOTE: tm-i386aix.h, tm-i386bsd.h, tm-i386os9k.h, tm-linux.h,
> Index: gdb/config/i386/tm-linux.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
> retrieving revision 1.16
> diff -c -r1.16 tm-linux.h
> *** gdb/config/i386/tm-linux.h	2001/11/08 00:03:52	1.16
> --- gdb/config/i386/tm-linux.h	2002/02/06 19:19:28
> ***************
> *** 82,87 ****
> --- 82,98 ----
>   #define IN_SIGTRAMP(pc, name) i386_linux_in_sigtramp (pc, name)
>   extern int i386_linux_in_sigtramp (CORE_ADDR, char *);
>   
> + /* On Linux, the entry point is called _start, but that invokes
> +    something called __libc_start_main, which calls main.  So if we
> +    want the stack to end at main (as it does for most GDB targets),
> +    it's not enough for us to use inside_entry_func or
> +    inside_entry_file; that rule will only trigger after we've included
> +    __libc_start_main in the backtrace, which we don't want.
> +    func_frame_chain_valid checks both for `main', and for the entry
> +    point function.  */
> + /* Use the alternate method of determining valid frame chains. */
> + #define FRAME_CHAIN_VALID(fp,fi) func_frame_chain_valid (fp, fi)
> + 
>   #undef FRAME_CHAIN
>   #define FRAME_CHAIN(frame) i386_linux_frame_chain (frame)
>   extern CORE_ADDR i386_linux_frame_chain (struct frame_info *frame);
> 

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