[RFA] Remove calls to inside_entry_file

[RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

Hi,

according to my RFC on the gdb mailing list

  http://sources.redhat.com/ml/gdb/2003-03/msg00358.html

I'm now proposing to remove calls to inside_entry_func entirely from
the generic code.  Additionally I've removed the call from
i386_frame_chain with no regressions on Linux and 7 new PASSes instead
of FAILs on Cygwin.

Corinna

2003-03-26  Corinna Vinschen  <vinschen@redhat.com>

        * blockframe.c (frame_chain_valid): Remove call to inside_entry_file().
        * frame.c (get_prev_frame): Ditto.
	* i386-tdep.c (i386_frame_chain): Ditto.

Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.65
diff -u -p -r1.65 blockframe.c
--- blockframe.c	24 Mar 2003 03:54:47 -0000	1.65
+++ blockframe.c	27 Mar 2003 11:25:19 -0000
@@ -580,13 +580,6 @@ frame_chain_valid (CORE_ADDR fp, struct 
   if (inside_entry_func (get_frame_pc (fi)))
     return 0;
 
-  /* If we're inside the entry file, it isn't valid.  */
-  /* NOTE/drow 2002-12-25: should there be a way to disable this check?  It
-     assumes a single small entry file, and the way some debug readers (e.g.
-     dbxread) figure out which object is the entry file is somewhat hokey.  */
-  if (inside_entry_file (frame_pc_unwind (fi)))
-      return 0;
-
   /* If the architecture has a custom DEPRECATED_FRAME_CHAIN_VALID,
      call it now.  */
   if (DEPRECATED_FRAME_CHAIN_VALID_P ())
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.89
diff -u -p -r1.89 frame.c
--- frame.c	26 Mar 2003 00:00:07 -0000	1.89
+++ frame.c	27 Mar 2003 11:25:20 -0000
@@ -1419,26 +1419,6 @@ get_prev_frame (struct frame_info *this_
     return this_frame->prev;
   this_frame->prev_p = 1;
 
-  /* If we're inside the entry file, it isn't valid.  Don't apply this
-     test to a dummy frame - dummy frame PC's typically land in the
-     entry file.  Don't apply this test to the sentinel frame.
-     Sentinel frames should always be allowed to unwind.  */
-  /* NOTE: drow/2002-12-25: should there be a way to disable this
-     check?  It assumes a single small entry file, and the way some
-     debug readers (e.g.  dbxread) figure out which object is the
-     entry file is somewhat hokey.  */
-  /* NOTE: cagney/2003-01-10: If there is a way of disabling this test
-     then it should probably be moved to before the ->prev_p test,
-     above.  */
-  if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0
-      && inside_entry_file (get_frame_pc (this_frame)))
-    {
-      if (frame_debug)
-	fprintf_unfiltered (gdb_stdlog,
-			    "Outermost frame - inside entry file\n");
-      return NULL;
-    }
-
   /* If we're already inside the entry function for the main objfile,
      then it isn't valid.  Don't apply this test to a dummy frame -
      dummy frame PC's typically land in the entry func.  Don't apply
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.123
diff -u -p -r1.123 i386-tdep.c
--- i386-tdep.c	26 Mar 2003 22:39:52 -0000	1.123
+++ i386-tdep.c	27 Mar 2003 11:25:21 -0000
@@ -519,10 +519,7 @@ i386_frame_chain (struct frame_info *fra
       || i386_frameless_signal_p (frame))
     return get_frame_base (frame);
 
-  if (! inside_entry_file (get_frame_pc (frame)))
-    return read_memory_unsigned_integer (get_frame_base (frame), 4);
-
-  return 0;
+  return read_memory_unsigned_integer (get_frame_base (frame), 4);
 }
 
 /* Determine whether the function invocation represented by FRAME does

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

> Hi,
> 
> according to my RFC on the gdb mailing list
> 
>   http://sources.redhat.com/ml/gdb/2003-03/msg00358.html
> 
> I'm now proposing to remove calls to inside_entry_func entirely from
> the generic code.  Additionally I've removed the call from
> i386_frame_chain with no regressions on Linux and 7 new PASSes instead
> of FAILs on Cygwin.

> Index: blockframe.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/blockframe.c,v

For "blockframe.c", please leave it as is.  I'm already in enough 
trouble for breaking old targets so I'd prefer to leave that part 
untouched.  It would only affect out-of-date targets anyway.  The 
up-to-date targets don't rely on that function.

> Index: frame.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/frame.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 frame.c
> --- frame.c	26 Mar 2003 00:00:07 -0000	1.89
> +++ frame.c	27 Mar 2003 11:25:20 -0000
> @@ -1419,26 +1419,6 @@ get_prev_frame (struct frame_info *this_
>      return this_frame->prev;
>    this_frame->prev_p = 1;
>  
> -  /* If we're inside the entry file, it isn't valid.  Don't apply this
> -     test to a dummy frame - dummy frame PC's typically land in the
> -     entry file.  Don't apply this test to the sentinel frame.
> -     Sentinel frames should always be allowed to unwind.  */
> -  /* NOTE: drow/2002-12-25: should there be a way to disable this
> -     check?  It assumes a single small entry file, and the way some
> -     debug readers (e.g.  dbxread) figure out which object is the
> -     entry file is somewhat hokey.  */
> -  /* NOTE: cagney/2003-01-10: If there is a way of disabling this test
> -     then it should probably be moved to before the ->prev_p test,
> -     above.  */
> -  if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0
> -      && inside_entry_file (get_frame_pc (this_frame)))
> -    {
> -      if (frame_debug)
> -	fprintf_unfiltered (gdb_stdlog,
> -			    "Outermost frame - inside entry file\n");
> -      return NULL;
> -    }
> -
>    /* If we're already inside the entry function for the main objfile,
>       then it isn't valid.  Don't apply this test to a dummy frame -
>       dummy frame PC's typically land in the entry func.  Don't apply

For "frame.c", it doesn't break the current d10v and that is the only 
target that the change would affect..  Rather than deleting the code, 
though, can you instead disable it vis:

	if (0
	    && ....

and then add a comment giving a detailed rationale for why the test was 
disabled.  Consider that approved.

If the code is simply deleted, that knowledge will be lost, and in 6 
months time we'll have someone trying to add that exact same test again ...

> Index: i386-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-tdep.c,v
> retrieving revision 1.123
> diff -u -p -r1.123 i386-tdep.c
> --- i386-tdep.c	26 Mar 2003 22:39:52 -0000	1.123
> +++ i386-tdep.c	27 Mar 2003 11:25:21 -0000

Please post the i386 change separatly, that way it is easier for the 
i386 maintainers to identify/review.  I've no idea.  The function may 
well have been rewritten.  frame_chain is deprecated.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

Andrew,

On Fri, Mar 28, 2003 at 07:28:36PM -0500, Andrew Cagney wrote:
> >Index: blockframe.c
> >===================================================================
> >RCS file: /cvs/src/src/gdb/blockframe.c,v
> 
> For "blockframe.c", please leave it as is.  I'm already in enough 
> trouble for breaking old targets so I'd prefer to leave that part 
> untouched.  It would only affect out-of-date targets anyway.  The 
> up-to-date targets don't rely on that function.

I've checked in the frame.c patch but still, I don't understand this
decision.  So called out-of-date targets can easily add the
inside_entry_file() call to their frame_chain_valid() implementation
so removing this call from blockframe.c does not necessarily break
them.  Keeping this call in blockframe.c on the other hand breaks
some targets for which this call is plainly wrong.  So the logic would
imply to remove the call in favour of *all* targets able to run correctly.

I've checked this patch (including the patch to i386_frame_chain_valid)
on four targets, xstormy16-elf, i686-pc-cygwin, i686-pc-linux and arm-elf.
The first two are running fine then, the latter two are totally
unaffected.


Corinna

P.S.: I'll submit the i386_frame_chain_valid patch separately.

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Tue, Apr 01, 2003 at 05:31:25PM +0200, Corinna Vinschen wrote:
> Andrew,
> 
> On Fri, Mar 28, 2003 at 07:28:36PM -0500, Andrew Cagney wrote:
> > >Index: blockframe.c
> > >===================================================================
> > >RCS file: /cvs/src/src/gdb/blockframe.c,v
> > 
> > For "blockframe.c", please leave it as is.  I'm already in enough 
> > trouble for breaking old targets so I'd prefer to leave that part 
> > untouched.  It would only affect out-of-date targets anyway.  The 
> > up-to-date targets don't rely on that function.
> 
> I've checked in the frame.c patch but still, I don't understand this
> decision.  So called out-of-date targets can easily add the
> inside_entry_file() call to their frame_chain_valid() implementation
                                    ^^^^^^^^^^^^^^^^^^^
                                      frame_chain()

> so removing this call from blockframe.c does not necessarily break
> them.  Keeping this call in blockframe.c on the other hand breaks
> some targets for which this call is plainly wrong.  So the logic would
> imply to remove the call in favour of *all* targets able to run correctly.
> 
> I've checked this patch (including the patch to i386_frame_chain_valid)
> on four targets, xstormy16-elf, i686-pc-cygwin, i686-pc-linux and arm-elf.
> The first two are running fine then, the latter two are totally
> unaffected.
> 
> 
> Corinna
> 
> P.S.: I'll submit the i386_frame_chain_valid patch separately.
                        ^^^^^^^^^^^^^^^^^^^^^^
                          i386_frame_chain()

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

> Andrew,
> 
> On Fri, Mar 28, 2003 at 07:28:36PM -0500, Andrew Cagney wrote:
> 
>> >Index: blockframe.c
>> >===================================================================
>> >RCS file: /cvs/src/src/gdb/blockframe.c,v
> 
>> 
>> For "blockframe.c", please leave it as is.  I'm already in enough 
>> trouble for breaking old targets so I'd prefer to leave that part 
>> untouched.  It would only affect out-of-date targets anyway.  The 
>> up-to-date targets don't rely on that function.
> 
> 
> I've checked in the frame.c patch but still, I don't understand this
> decision.  So called out-of-date targets can easily add the
> inside_entry_file() call to their frame_chain_valid() implementation
> so removing this call from blockframe.c does not necessarily break
> them.  Keeping this call in blockframe.c on the other hand breaks
> some targets for which this call is plainly wrong.  So the logic would
> imply to remove the call in favour of *all* targets able to run correctly.
> 
> I've checked this patch (including the patch to i386_frame_chain_valid)
> on four targets, xstormy16-elf, i686-pc-cygwin, i686-pc-linux and arm-elf.
> The first two are running fine then, the latter two are totally
> unaffected.

You want to run arm and i386 changes past their respective maintainers.

Andrew

PS: Patch?

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Tue, Apr 01, 2003 at 10:39:22AM -0500, Andrew Cagney wrote:
> >Andrew,
> >
> >On Fri, Mar 28, 2003 at 07:28:36PM -0500, Andrew Cagney wrote:
> >
> >>>Index: blockframe.c
> >>>===================================================================
> >>>RCS file: /cvs/src/src/gdb/blockframe.c,v
> >
> >>
> >>For "blockframe.c", please leave it as is.  I'm already in enough 
> >>trouble for breaking old targets so I'd prefer to leave that part 
> >>untouched.  It would only affect out-of-date targets anyway.  The 
> >>up-to-date targets don't rely on that function.
> >
> >
> >I've checked in the frame.c patch but still, I don't understand this
> >decision.  So called out-of-date targets can easily add the
> >inside_entry_file() call to their frame_chain_valid() implementation
> >so removing this call from blockframe.c does not necessarily break
> >them.  Keeping this call in blockframe.c on the other hand breaks
> >some targets for which this call is plainly wrong.  So the logic would
> >imply to remove the call in favour of *all* targets able to run correctly.
> >
> >I've checked this patch (including the patch to i386_frame_chain_valid)
> >on four targets, xstormy16-elf, i686-pc-cygwin, i686-pc-linux and arm-elf.
> >The first two are running fine then, the latter two are totally
> >unaffected.
> 
> You want to run arm and i386 changes past their respective maintainers.

Misunderstanding?  I *tested* the above changes against xstormy16-elf,
i686-pc-cygwin, i686-pc-linux and arm-elf.  There are no arm-elf 
specific changes as well as no Linux specific changes.  There's a i386
patch which I've sent a few minutes ago.

Corinna

> Andrew
> 
> PS: Patch?

What patch are you talking about?

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

>> Andrew
>> 
>> PS: Patch?

The revised change you committed to frame.c?

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Tue, Apr 01, 2003 at 11:35:48AM -0500, Andrew Cagney wrote:
> 
> >>Andrew
> >>
> >>PS: Patch?
> 
> The revised change you committed to frame.c?

Oh, you wrote "Consider that approved" so I didn't thought I'd have
to send it again to gdb-patches.  However, what about the important
part of my posting:

>I've checked in the frame.c patch but still, I don't understand this
>decision.  So called out-of-date targets can easily add the
>inside_entry_file() call to their frame_chain_valid() implementation
>so removing this call from blockframe.c does not necessarily break
>them.  Keeping this call in blockframe.c on the other hand breaks
>some targets for which this call is plainly wrong.  So the logic would
>imply to remove the call in favour of *all* targets able to run correctly.

The patch to frame.c looks like this now:

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -p -r1.91 -r1.92
--- frame.c	31 Mar 2003 19:01:19 -0000	1.91
+++ frame.c	1 Apr 2003 15:26:08 -0000	1.92
@@ -1428,6 +1428,7 @@ get_prev_frame (struct frame_info *this_
     return this_frame->prev;
   this_frame->prev_p = 1;
 
+#if 0
   /* If we're inside the entry file, it isn't valid.  Don't apply this
      test to a dummy frame - dummy frame PC's typically land in the
      entry file.  Don't apply this test to the sentinel frame.
@@ -1439,6 +1440,15 @@ get_prev_frame (struct frame_info *this_
   /* NOTE: cagney/2003-01-10: If there is a way of disabling this test
      then it should probably be moved to before the ->prev_p test,
      above.  */
+  /* NOTE: vinschen/2003-04-01: Disabled.  It turns out that the call to
+     inside_entry_file destroys a meaningful backtrace under some
+     conditions.  E. g. the backtrace tests in the asm-source testcase
+     are broken for some targets.  In this test the functions are all
+     implemented as part of one file and the testcase is not necessarily
+     linked with a start file (depending on the target).  What happens is,
+     that the first frame is printed normaly and following frames are
+     treated as being inside the enttry file then.  This way, only the
+     #0 frame is printed in the backtrace output.  */
   if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0
       && inside_entry_file (get_frame_pc (this_frame)))
     {
@@ -1447,6 +1457,7 @@ get_prev_frame (struct frame_info *this_
 			    "Outermost frame - inside entry file\n");
       return NULL;
     }
+#endif
 
   /* If we're already inside the entry function for the main objfile,
      then it isn't valid.  Don't apply this test to a dummy frame -

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

> 
> Oh, you wrote "Consider that approved" so I didn't thought I'd have
> to send it again to gdb-patches.  However, what about the important
> part of my posting:

Yes, just please always post changes.

>>I've checked in the frame.c patch but still, I don't understand this
>>decision.  So called out-of-date targets can easily add the
>>inside_entry_file() call to their frame_chain_valid() implementation
>>so removing this call from blockframe.c does not necessarily break
>>them.  Keeping this call in blockframe.c on the other hand breaks
>>some targets for which this call is plainly wrong.  So the logic would
>>imply to remove the call in favour of *all* targets able to run correctly.

Per my previous comment, I'd prefer to not touch the old code at all - 
let it die.  Mark, I'll note, already has i386 replacement code in waiting.

The other thing to do is to ask DanielJ if he knows anything more about 
that specific case.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Tue, Apr 01, 2003 at 12:30:49PM -0500, Andrew Cagney wrote:
> >
> >Oh, you wrote "Consider that approved" so I didn't thought I'd have
> >to send it again to gdb-patches.  However, what about the important
> >part of my posting:
> 
> Yes, just please always post changes.
> 
> >>I've checked in the frame.c patch but still, I don't understand this
> >>decision.  So called out-of-date targets can easily add the
> >>inside_entry_file() call to their frame_chain_valid() implementation
> >>so removing this call from blockframe.c does not necessarily break
> >>them.  Keeping this call in blockframe.c on the other hand breaks
> >>some targets for which this call is plainly wrong.  So the logic would
> >>imply to remove the call in favour of *all* targets able to run correctly.
> 
> Per my previous comment, I'd prefer to not touch the old code at all - 
> let it die.  Mark, I'll note, already has i386 replacement code in waiting.
> 
> The other thing to do is to ask DanielJ if he knows anything more about 
> that specific case.

Nope.  It was there before I put my hands on it; it seems suspicious to
me though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Tue, Apr 01, 2003 at 02:58:32PM -0500, Daniel Jacobowitz wrote:
> On Tue, Apr 01, 2003 at 12:30:49PM -0500, Andrew Cagney wrote:
> > >
> > >Oh, you wrote "Consider that approved" so I didn't thought I'd have
> > >to send it again to gdb-patches.  However, what about the important
> > >part of my posting:
> > 
> > Yes, just please always post changes.
> > 
> > >>I've checked in the frame.c patch but still, I don't understand this
> > >>decision.  So called out-of-date targets can easily add the
> > >>inside_entry_file() call to their frame_chain_valid() implementation
> > >>so removing this call from blockframe.c does not necessarily break
> > >>them.  Keeping this call in blockframe.c on the other hand breaks
> > >>some targets for which this call is plainly wrong.  So the logic would
> > >>imply to remove the call in favour of *all* targets able to run correctly.
> > 
> > Per my previous comment, I'd prefer to not touch the old code at all - 
> > let it die.  Mark, I'll note, already has i386 replacement code in waiting.
> > 
> > The other thing to do is to ask DanielJ if he knows anything more about 
> > that specific case.
> 
> Nope.  It was there before I put my hands on it; it seems suspicious to
> me though.

What do you mean by "suspicious"?  You did already comment on this in
blockframe.c so I assume you had rather mixed feelings about this call.

I don't see a reason not to change this.  It will take some time to
move all targets to the new scheme.  Why should some of the not converted
targets remain broken due to an obvious bug?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

>> > Per my previous comment, I'd prefer to not touch the old code at all - 
>> > let it die.  Mark, I'll note, already has i386 replacement code in waiting.
>> > 
>> > The other thing to do is to ask DanielJ if he knows anything more about 
>> > that specific case.
> 
>> 
>> Nope.  It was there before I put my hands on it; it seems suspicious to
>> me though.
> 
> 
> What do you mean by "suspicious"?  You did already comment on this in
> blockframe.c so I assume you had rather mixed feelings about this call.
> 
> I don't see a reason not to change this.  It will take some time to
> move all targets to the new scheme.  Why should some of the not converted
> targets remain broken due to an obvious bug?

I'm beginning to think that reverting some of the original change:

RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html

might be the best option.  What about moving this:

 > +
 > +  /* If the architecture has a custom FRAME_CHAIN_VALID, call it 
now.  */
 > +  if (FRAME_CHAIN_VALID_P ())
 > +    return FRAME_CHAIN_VALID (fp, fi);

to before this:

+  /* If we're already inside the entry function for the main objfile, 
then it
+     isn't valid.  */
+  if (inside_entry_func (get_frame_pc (fi)))
+    return 0;
+
+  /* If we're inside the entry file, it isn't valid.  */
+  /* NOTE/drow 2002-12-25: should there be a way to disable this check?  It
+     assumes a single small entry file, and the way some debug readers 
(e.g.
+     dbxread) figure out which object is the entry file is somewhat 
hokey.  */
+  if (inside_entry_file (frame_pc_unwind (fi)))
+      return 0;
+
+  /* If we want backtraces to stop at main, and we're inside main, then it
+     isn't valid.  */
+  if (!backtrace_below_main && inside_main_func (get_frame_pc (fi)))
+    return 0;

That more closely resembles the original behavior.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Wed, Apr 02, 2003 at 11:27:41AM +0200, Corinna Vinschen wrote:
> On Tue, Apr 01, 2003 at 02:58:32PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Apr 01, 2003 at 12:30:49PM -0500, Andrew Cagney wrote:
> > > >
> > > >Oh, you wrote "Consider that approved" so I didn't thought I'd have
> > > >to send it again to gdb-patches.  However, what about the important
> > > >part of my posting:
> > > 
> > > Yes, just please always post changes.
> > > 
> > > >>I've checked in the frame.c patch but still, I don't understand this
> > > >>decision.  So called out-of-date targets can easily add the
> > > >>inside_entry_file() call to their frame_chain_valid() implementation
> > > >>so removing this call from blockframe.c does not necessarily break
> > > >>them.  Keeping this call in blockframe.c on the other hand breaks
> > > >>some targets for which this call is plainly wrong.  So the logic would
> > > >>imply to remove the call in favour of *all* targets able to run correctly.
> > > 
> > > Per my previous comment, I'd prefer to not touch the old code at all - 
> > > let it die.  Mark, I'll note, already has i386 replacement code in waiting.
> > > 
> > > The other thing to do is to ask DanielJ if he knows anything more about 
> > > that specific case.
> > 
> > Nope.  It was there before I put my hands on it; it seems suspicious to
> > me though.
> 
> What do you mean by "suspicious"?  You did already comment on this in
> blockframe.c so I assume you had rather mixed feelings about this call.

By "suspicious" I mean that I don't see why it would be necessary.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Wed, Apr 02, 2003 at 11:36:08AM -0500, Andrew Cagney wrote:
> 
> >>> Per my previous comment, I'd prefer to not touch the old code at all - 
> >>> let it die.  Mark, I'll note, already has i386 replacement code in 
> >>waiting.
> >>> 
> >>> The other thing to do is to ask DanielJ if he knows anything more about 
> >>> that specific case.
> >
> >>
> >>Nope.  It was there before I put my hands on it; it seems suspicious to
> >>me though.
> >
> >
> >What do you mean by "suspicious"?  You did already comment on this in
> >blockframe.c so I assume you had rather mixed feelings about this call.
> >
> >I don't see a reason not to change this.  It will take some time to
> >move all targets to the new scheme.  Why should some of the not converted
> >targets remain broken due to an obvious bug?
> 
> I'm beginning to think that reverting some of the original change:
> 
> RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
> http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
> 
> might be the best option.  What about moving this:

I just want to make sure you realize that doing so would defeat the
point of the patch, which was to have the other quoted checks below
apply to all targets.  I'm trying to make the target-specific hooks
less powerful, not more.

But I guess this conversation's gone on so long that I've lost track of
what why this is causing a problem.  So maybe I'm missing something
important.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

>> I'm beginning to think that reverting some of the original change:
>> 
>> RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
>> http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
>> 
>> might be the best option.  What about moving this:
> 
> 
> I just want to make sure you realize that doing so would defeat the
> point of the patch, which was to have the other quoted checks below
> apply to all targets.  I'm trying to make the target-specific hooks
> less powerful, not more.
> 
> But I guess this conversation's gone on so long that I've lost track of
> what why this is causing a problem.  So maybe I'm missing something
> important.

The original change broke assembler backtraces for at least xstormy16 
and cygwin.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Wed, Apr 02, 2003 at 12:02:58PM -0500, Andrew Cagney wrote:
> 
> >>I'm beginning to think that reverting some of the original change:
> >>
> >>RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
> >>http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
> >>
> >>might be the best option.  What about moving this:
> >
> >
> >I just want to make sure you realize that doing so would defeat the
> >point of the patch, which was to have the other quoted checks below
> >apply to all targets.  I'm trying to make the target-specific hooks
> >less powerful, not more.
> >
> >But I guess this conversation's gone on so long that I've lost track of
> >what why this is causing a problem.  So maybe I'm missing something
> >important.
> 
> The original change broke assembler backtraces for at least xstormy16 
> and cygwin.

Right, thanks.

If we want this to work - which is explicitly a backtrace into the
entry file - then we should probably just kill the test.  If it causes
a problem somewhere, we can deal with it, but I don't expect it will.

Just my two cents.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

> On Wed, Apr 02, 2003 at 12:02:58PM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >>I'm beginning to think that reverting some of the original change:
>> >>
>> >>RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
>> >>http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
>> >>
>> >>might be the best option.  What about moving this:
> 
>> >
>> >
>> >I just want to make sure you realize that doing so would defeat the
>> >point of the patch, which was to have the other quoted checks below
>> >apply to all targets.  I'm trying to make the target-specific hooks
>> >less powerful, not more.
>> >
>> >But I guess this conversation's gone on so long that I've lost track of
>> >what why this is causing a problem.  So maybe I'm missing something
>> >important.
> 
>> 
>> The original change broke assembler backtraces for at least xstormy16 
>> and cygwin.
> 
> 
> Right, thanks.
> 
> If we want this to work - which is explicitly a backtrace into the
> entry file - then we should probably just kill the test.  If it causes
> a problem somewhere, we can deal with it, but I don't expect it will.

Keep in mind that the frame_chain_valid() function has been 
end-of-life'ed, and the original change has been superseeded by the 
get_prev_frame().  Given that, I think the best thing to do is to 
restore the old behavior for older targets - hence put that test first.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Wed, Apr 02, 2003 at 01:20:20PM -0500, Andrew Cagney wrote:
> >On Wed, Apr 02, 2003 at 12:02:58PM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>>I'm beginning to think that reverting some of the original change:
> >>>>
> >>>>RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
> >>>>http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
> >>>>
> >>>>might be the best option.  What about moving this:
> >
> >>>
> >>>
> >>>I just want to make sure you realize that doing so would defeat the
> >>>point of the patch, which was to have the other quoted checks below
> >>>apply to all targets.  I'm trying to make the target-specific hooks
> >>>less powerful, not more.
> >>>
> >>>But I guess this conversation's gone on so long that I've lost track of
> >>>what why this is causing a problem.  So maybe I'm missing something
> >>>important.
> >
> >>
> >>The original change broke assembler backtraces for at least xstormy16 
> >>and cygwin.
> >
> >
> >Right, thanks.
> >
> >If we want this to work - which is explicitly a backtrace into the
> >entry file - then we should probably just kill the test.  If it causes
> >a problem somewhere, we can deal with it, but I don't expect it will.
> 
> Keep in mind that the frame_chain_valid() function has been 
> end-of-life'ed, and the original change has been superseeded by the 
> get_prev_frame().  Given that, I think the best thing to do is to 
> restore the old behavior for older targets - hence put that test first.

That will cause many targets to start backtracing past main, which I
believe we agreed was undesirable.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

> Right, thanks.
>> >
>> >If we want this to work - which is explicitly a backtrace into the
>> >entry file - then we should probably just kill the test.  If it causes
>> >a problem somewhere, we can deal with it, but I don't expect it will.
> 
>> 
>> Keep in mind that the frame_chain_valid() function has been 
>> end-of-life'ed, and the original change has been superseeded by the 
>> get_prev_frame().  Given that, I think the best thing to do is to 
>> restore the old behavior for older targets - hence put that test first.
> 
> 
> That will cause many targets to start backtracing past main, which I
> believe we agreed was undesirable.

Restore the old behavior as far as frame_chain_valid() is concerned. 
The main() check was moved to get_prev_frame() some time ago.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Daniel Jacobowitz]

On Wed, Apr 02, 2003 at 02:25:45PM -0500, Andrew Cagney wrote:
> >Right, thanks.
> >>>
> >>>If we want this to work - which is explicitly a backtrace into the
> >>>entry file - then we should probably just kill the test.  If it causes
> >>>a problem somewhere, we can deal with it, but I don't expect it will.
> >
> >>
> >>Keep in mind that the frame_chain_valid() function has been 
> >>end-of-life'ed, and the original change has been superseeded by the 
> >>get_prev_frame().  Given that, I think the best thing to do is to 
> >>restore the old behavior for older targets - hence put that test first.
> >
> >
> >That will cause many targets to start backtracing past main, which I
> >believe we agreed was undesirable.
> 
> Restore the old behavior as far as frame_chain_valid() is concerned. 
> The main() check was moved to get_prev_frame() some time ago.

You're right, I see it now.  OK then.

I don't care; someday it'll all go away.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Wed, Apr 02, 2003 at 11:36:08AM -0500, Andrew Cagney wrote:
> I'm beginning to think that reverting some of the original change:
> 
> RFC: Mostly kill FRAME_CHAIN_VALID, add user knob
> http://sources.redhat.com/ml/gdb-patches/2002-12/msg00683.html
> 
> might be the best option.  What about moving this:
> 
> > +
> > +  /* If the architecture has a custom FRAME_CHAIN_VALID, call it 
> now.  */
> > +  if (FRAME_CHAIN_VALID_P ())
> > +    return FRAME_CHAIN_VALID (fp, fi);
> 
> to before this:
> 
> +  /* If we're already inside the entry function for the main objfile, 
> then it
> +     isn't valid.  */
> +  if (inside_entry_func (get_frame_pc (fi)))
> +    return 0;
> +
> +  /* If we're inside the entry file, it isn't valid.  */
> +  /* NOTE/drow 2002-12-25: should there be a way to disable this check?  It
> +     assumes a single small entry file, and the way some debug readers 
> (e.g.
> +     dbxread) figure out which object is the entry file is somewhat 
> hokey.  */
> +  if (inside_entry_file (frame_pc_unwind (fi)))
> +      return 0;
> +
> +  /* If we want backtraces to stop at main, and we're inside main, then it
> +     isn't valid.  */
> +  if (!backtrace_below_main && inside_main_func (get_frame_pc (fi)))
> +    return 0;
> 
> That more closely resembles the original behavior.

I think that's pretty much ok.  Old targets in need of one of these functions
can still call it from (deprecated_)frame_chain_valid().

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [RFA] Remove calls to inside_entry_file

[Andrew Cagney]

>> might be the best option.  What about moving this:
>> 
> 
>> > +
>> > +  /* If the architecture has a custom FRAME_CHAIN_VALID, call it 
> 
>> now.  */
> 
>> > +  if (FRAME_CHAIN_VALID_P ())
>> > +    return FRAME_CHAIN_VALID (fp, fi);
> 
>> 
>> to before this:
>> 
>> +  /* If we're already inside the entry function for the main objfile, 
>> then it
>> +     isn't valid.  */
>> +  if (inside_entry_func (get_frame_pc (fi)))
>> +    return 0;
>> +
>> +  /* If we're inside the entry file, it isn't valid.  */
>> +  /* NOTE/drow 2002-12-25: should there be a way to disable this check?  It
>> +     assumes a single small entry file, and the way some debug readers 
>> (e.g.
>> +     dbxread) figure out which object is the entry file is somewhat 
>> hokey.  */
>> +  if (inside_entry_file (frame_pc_unwind (fi)))
>> +      return 0;
>> +
>> +  /* If we want backtraces to stop at main, and we're inside main, then it
>> +     isn't valid.  */
>> +  if (!backtrace_below_main && inside_main_func (get_frame_pc (fi)))
>> +    return 0;
>> 
>> That more closely resembles the original behavior.
> 
> 
> I think that's pretty much ok.  Old targets in need of one of these functions
> can still call it from (deprecated_)frame_chain_valid().

Ok, sold.

Consider that approved.

Andrew

Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen]

On Sat, Apr 05, 2003 at 08:56:54AM -0500, Andrew Cagney wrote:
> Consider that approved.

Thanks, applied.

Corinna


2003-04-10  Corinna Vinschen  <vinschen@redhat.com>

        * blockframe.c (legacy_frame_chain_valid): Move call to
	DEPRECATED_FRAME_CHAIN_VALID before calls to inside_entry_func and
	inside_entry_file.

Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.67
diff -u -p -r1.67 blockframe.c
--- blockframe.c	6 Apr 2003 18:36:22 -0000	1.67
+++ blockframe.c	10 Apr 2003 11:09:32 -0000
@@ -575,6 +575,11 @@ legacy_frame_chain_valid (CORE_ADDR fp, 
   if (INNER_THAN (fp, get_frame_base (fi)))
     return 0;
   
+  /* If the architecture has a custom DEPRECATED_FRAME_CHAIN_VALID,
+     call it now.  */
+  if (DEPRECATED_FRAME_CHAIN_VALID_P ())
+    return DEPRECATED_FRAME_CHAIN_VALID (fp, fi);
+
   /* If we're already inside the entry function for the main objfile, then it
      isn't valid.  */
   if (inside_entry_func (get_frame_pc (fi)))
@@ -586,11 +591,6 @@ legacy_frame_chain_valid (CORE_ADDR fp, 
      dbxread) figure out which object is the entry file is somewhat hokey.  */
   if (inside_entry_file (frame_pc_unwind (fi)))
       return 0;
-
-  /* If the architecture has a custom DEPRECATED_FRAME_CHAIN_VALID,
-     call it now.  */
-  if (DEPRECATED_FRAME_CHAIN_VALID_P ())
-    return DEPRECATED_FRAME_CHAIN_VALID (fp, fi);
 
   return 1;
 }

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com