[PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Kevin Buettner]

An FR-V user reported being unable to see useful backtraces when
debugging functions inside the entry file.  This patch fixes that
problem.  I think there's a problem with inside_entry_func() itself,
but that's a separate issue.  (If you are in the entry file,
backtraces don't stop at the entry func - they attempt to continue
beyond, but they do stop shortly thereafter.)

Committed.

Kevin

	* frv-tdep.c (frv_frame_this_id): Call inside_entry_func()
	instead of deprecated_inside_entry_file().

Index: frv-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/frv-tdep.c,v
retrieving revision 1.54
diff -u -p -r1.54 frv-tdep.c
--- frv-tdep.c	14 Oct 2003 00:30:27 -0000	1.54
+++ frv-tdep.c	14 Oct 2003 20:40:18 -0000
@@ -1009,7 +1009,7 @@ frv_frame_this_id (struct frame_info *ne
 
   /* This is meant to halt the backtrace at "_start".  Make sure we
      don't halt it at a generic dummy frame. */
-  if (deprecated_inside_entry_file (func))
+  if (inside_entry_func (func))
     return;
 
   /* Check if the stack is empty.  */

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Andrew Cagney]

> An FR-V user reported being unable to see useful backtraces when
> debugging functions inside the entry file.  This patch fixes that
> problem.  I think there's a problem with inside_entry_func() itself,
> but that's a separate issue.  (If you are in the entry file,
> backtraces don't stop at the entry func - they attempt to continue
> beyond, but they do stop shortly thereafter.)

What happens if that test is removed?

I believe the below test has its origins in a d10v hack to get around 
what was then a broken back-trace-past-main problem.  The problems been 
fixed, but unfortunatly, the original hack keeps turning up.

Andrew


> Kevin
> 
> 	* frv-tdep.c (frv_frame_this_id): Call inside_entry_func()
> 	instead of deprecated_inside_entry_file().
> 
> Index: frv-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/frv-tdep.c,v
> retrieving revision 1.54
> diff -u -p -r1.54 frv-tdep.c
> --- frv-tdep.c	14 Oct 2003 00:30:27 -0000	1.54
> +++ frv-tdep.c	14 Oct 2003 20:40:18 -0000
> @@ -1009,7 +1009,7 @@ frv_frame_this_id (struct frame_info *ne
>  
>    /* This is meant to halt the backtrace at "_start".  Make sure we
>       don't halt it at a generic dummy frame. */
> -  if (deprecated_inside_entry_file (func))
> +  if (inside_entry_func (func))
>      return;
>  
>    /* Check if the stack is empty.  */
> 

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Michael Snyder]

Andrew Cagney wrote:
>> An FR-V user reported being unable to see useful backtraces when
>> debugging functions inside the entry file.  This patch fixes that
>> problem.  I think there's a problem with inside_entry_func() itself,
>> but that's a separate issue.  (If you are in the entry file,
>> backtraces don't stop at the entry func - they attempt to continue
>> beyond, but they do stop shortly thereafter.)
> 
> 
> What happens if that test is removed?
> 
> I believe the below test has its origins in a d10v hack to get around 
> what was then a broken back-trace-past-main problem.  The problems been 
> fixed, but unfortunatly, the original hack keeps turning up.

Checking for the entry file/function?  Oh, it's older than that...


>> Kevin
>>
>>     * frv-tdep.c (frv_frame_this_id): Call inside_entry_func()
>>     instead of deprecated_inside_entry_file().
>>
>> Index: frv-tdep.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/frv-tdep.c,v
>> retrieving revision 1.54
>> diff -u -p -r1.54 frv-tdep.c
>> --- frv-tdep.c    14 Oct 2003 00:30:27 -0000    1.54
>> +++ frv-tdep.c    14 Oct 2003 20:40:18 -0000
>> @@ -1009,7 +1009,7 @@ frv_frame_this_id (struct frame_info *ne
>>  
>>    /* This is meant to halt the backtrace at "_start".  Make sure we
>>       don't halt it at a generic dummy frame. */
>> -  if (deprecated_inside_entry_file (func))
>> +  if (inside_entry_func (func))
>>      return;
>>  
>>    /* Check if the stack is empty.  */
>>
> 
> 
> 

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Kevin Buettner]

On Oct 14,  5:55pm, Andrew Cagney wrote:

> > An FR-V user reported being unable to see useful backtraces when
> > debugging functions inside the entry file.  This patch fixes that
> > problem.  I think there's a problem with inside_entry_func() itself,
> > but that's a separate issue.  (If you are in the entry file,
> > backtraces don't stop at the entry func - they attempt to continue
> > beyond, but they do stop shortly thereafter.)
> 
> What happens if that test is removed?

At the moment, the behavior is the same whether the test is there or
not.  That is, things work as expected so long as your're in main()
or above.  If you go below main(), then things break down.  The
inside_entry_func() test ought to stop backtraces from going too
far, but for FR-V at least, it seems to be broken.

Here's an example of where things break down:

0x00010118 in _start ()
1: x/i $pc  0x10118 <_start+280>:       call 0x11dc0 <exit>
(gdb) bt
#0  0x00010118 in _start ()
#1  0x00018ed4 in _write_r (ptr=0x0, fd=0, buf=0x0, cnt=5)
    at /ocotillo2/devo-frv/frv-elf/bld/../../devo/newlib/libc/reent/writer.c:58
Previous frame inner to this frame (corrupt stack?)


Kevin

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Andrew Cagney]

> On Oct 14,  5:55pm, Andrew Cagney wrote:
> 
> 
>> > An FR-V user reported being unable to see useful backtraces when
>> > debugging functions inside the entry file.  This patch fixes that
>> > problem.  I think there's a problem with inside_entry_func() itself,
>> > but that's a separate issue.  (If you are in the entry file,
>> > backtraces don't stop at the entry func - they attempt to continue
>> > beyond, but they do stop shortly thereafter.)
> 
>> 
>> What happens if that test is removed?
> 
> 
> At the moment, the behavior is the same whether the test is there or
> not.  That is, things work as expected so long as your're in main()
> or above.  If you go below main(), then things break down.  The
> inside_entry_func() test ought to stop backtraces from going too
> far, but for FR-V at least, it seems to be broken.
> 
> Here's an example of where things break down:
> 
> 0x00010118 in _start ()
> 1: x/i $pc  0x10118 <_start+280>:       call 0x11dc0 <exit>
> (gdb) bt
> #0  0x00010118 in _start ()
> #1  0x00018ed4 in _write_r (ptr=0x0, fd=0, buf=0x0, cnt=5)
>     at /ocotillo2/devo-frv/frv-elf/bld/../../devo/newlib/libc/reent/writer.c:58
> Previous frame inner to this frame (corrupt stack?)

In that case, the test should be removed.  It definitly doesn't belong 
there.  Instead your ABI should specify a robust way of detecting a 
terminated stack.  For instance, the PPC specifies that the stack chain 
is ended with a ZERO entry.

Here's the relevant comments in "frame.c":

   /* 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
      this test to the sentinel frame.  Sentinel frames should always
      be allowed to unwind.  */
   /* NOTE: cagney/2003-02-25: Don't enable until someone has found
      hard evidence that this is needed.  */
   /* NOTE: cagney/2003-07-07: Fixed a bug in inside_main_func - wasn't
      checking for "main" in the minimal symbols.  With that fixed
      asm-source tests now stop in "main" instead of halting the
      backtrace in wierd and wonderful ways somewhere inside the entry
      file.  Suspect that deprecated_inside_entry_file and
      inside_entry_func tests were added to work around that (now
      fixed) case.  */
   /* NOTE: cagney/2003-07-15: danielj (if I'm reading it right)
      suggested having the inside_entry_func test use the
      inside_main_func msymbol trick (along with entry_point_address I
      guess) to determine the address range of the start function.
      That should provide a far better stopper than the current
      heuristics.  */
   /* NOTE: cagney/2003-07-15: Need to add a "set backtrace
      beyond-entry-func" command so that this can be selectively
      disabled.  */

I'd like to avoid re-introducing a dependency on inside_entry_func() as 
that places garish requirements on the object file readers :-(

I also suspect that just removing the test fixes the bug.  The other 
relevant comment is:

   /* 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.  */
   /* NOTE: vinschen/2003-04-01: Disabled.  It turns out that the call
      to deprecated_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.  */

Corinna disabled this for just the reason you describe.

Andrew

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Kevin Buettner]

On Oct 15,  9:14pm, Andrew Cagney wrote:

> > On Oct 14,  5:55pm, Andrew Cagney wrote:
> > 
> >> > An FR-V user reported being unable to see useful backtraces when
> >> > debugging functions inside the entry file.  This patch fixes that
> >> > problem.  I think there's a problem with inside_entry_func() itself,
> >> > but that's a separate issue.  (If you are in the entry file,
> >> > backtraces don't stop at the entry func - they attempt to continue
> >> > beyond, but they do stop shortly thereafter.)
> > 
> >> 
> >> What happens if that test is removed?
> > 
> > 
> > At the moment, the behavior is the same whether the test is there or
> > not.  That is, things work as expected so long as your're in main()
> > or above.  If you go below main(), then things break down.  The
> > inside_entry_func() test ought to stop backtraces from going too
> > far, but for FR-V at least, it seems to be broken.
> > 
> > Here's an example of where things break down:
> > 
> > 0x00010118 in _start ()
> > 1: x/i $pc  0x10118 <_start+280>:       call 0x11dc0 <exit>
> > (gdb) bt
> > #0  0x00010118 in _start ()
> > #1  0x00018ed4 in _write_r (ptr=0x0, fd=0, buf=0x0, cnt=5)
> >     at /ocotillo2/devo-frv/frv-elf/bld/../../devo/newlib/libc/reent/writer.c:58
> > Previous frame inner to this frame (corrupt stack?)
> 
> In that case, the test should be removed.  It definitly doesn't belong 
> there.  Instead your ABI should specify a robust way of detecting a 
> terminated stack.  For instance, the PPC specifies that the stack chain 
> is ended with a ZERO entry.

I've looked at the FR-V EABI, but I see no such specification. 
Tomorrow, I'll look at the startup code to see if I can figure out a
way to detect the bottom of the stack.  Even if I find something in
the startup code, I would hate to rely on it.  After all, startup
code can change.  It really would be best if we could reliably know
the bounds of the start function.  Note that this is quite a different
matter from the bounds of the start file which you refer to further
below.

> Here's the relevant comments in "frame.c":
> 
>    /* 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
>       this test to the sentinel frame.  Sentinel frames should always
>       be allowed to unwind.  */
>    /* NOTE: cagney/2003-02-25: Don't enable until someone has found
>       hard evidence that this is needed.  */
>    /* NOTE: cagney/2003-07-07: Fixed a bug in inside_main_func - wasn't
>       checking for "main" in the minimal symbols.  With that fixed
>       asm-source tests now stop in "main" instead of halting the
>       backtrace in wierd and wonderful ways somewhere inside the entry
>       file.  Suspect that deprecated_inside_entry_file and
>       inside_entry_func tests were added to work around that (now
>       fixed) case.  */
>    /* NOTE: cagney/2003-07-15: danielj (if I'm reading it right)
>       suggested having the inside_entry_func test use the
>       inside_main_func msymbol trick (along with entry_point_address I
>       guess) to determine the address range of the start function.
>       That should provide a far better stopper than the current
>       heuristics.  */
>    /* NOTE: cagney/2003-07-15: Need to add a "set backtrace
>       beyond-entry-func" command so that this can be selectively
>       disabled.  */
> 
> I'd like to avoid re-introducing a dependency on inside_entry_func() as 
> that places garish requirements on the object file readers :-(

I agree that object file readers should not attempt to track of
the bounds of the start function.  However, given an arbitrary
address, it's not unreasonable to ask the symtab machinery to attempt
to figure out the function bounds.  And, in fact, this is just what
find_pc_partial_function() does.

> I also suspect that just removing the test fixes the bug.

What bug?

As noted earlier, I'm seeing unwelcome behavior regardless of whether
the test is enabled or not.  I've looked at what's going on in
inside_entry_func() and have already determined that it's not working
properly for me.

> The other relevant comment is:
> 
>    /* 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.  */
>    /* NOTE: vinschen/2003-04-01: Disabled.  It turns out that the call
>       to deprecated_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.  */
> 
> Corinna disabled this for just the reason you describe.

Yes, I agree that deprecated_inside_entry_file() is a bad idea.  I
suspect it was being used because past and existing
implementations of inside_entry_func() proved to be unreliable.

Kevin

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Daniel Jacobowitz]

On Wed, Oct 15, 2003 at 08:31:45PM -0700, Kevin Buettner wrote:
> Yes, I agree that deprecated_inside_entry_file() is a bad idea.  I
> suspect it was being used because past and existing
> implementations of inside_entry_func() proved to be unreliable.

FYI, I have some local hacks for the dwarf2 reader that are needed to
use inside_entry_func reliably (or a number of other things...) in the
presence of discarded sections.  I'll try to remember to post them but
the gist is that until the linker does better, we need to detect
wildly-inaccurate bounds on DIEs and not adjust the compilation unit's
bounds (or the start function's, either).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file

[Andrew Cagney]

>> I'd like to avoid re-introducing a dependency on inside_entry_func() as 
>> that places garish requirements on the object file readers :-(
> 
> 
> I agree that object file readers should not attempt to track of
> the bounds of the start function.  However, given an arbitrary
> address, it's not unreasonable to ask the symtab machinery to attempt
> to figure out the function bounds.  And, in fact, this is just what
> find_pc_partial_function() does.

Begs the question.  How come it wasn't done that way originally?  Same 
for main()?

One common problem is badly written crt0.o files.  For instance:
	_start:
		set-sp-insn
		for-insn endloop
		clear-mem-insn
	endloop:
		call-insn main
should use numeric lables so that the symbol table code doesn't get 
tripped up thinking "endloop" is a function.

> > I also suspect that just removing the test fixes the bug.
> 
> 
> What bug?

The original one:  "An FR-V user reported being unable to see useful 
backtraces when debugging functions inside the entry file."

Removing the entry-file test gives the user a meaningful backtrace. 
(Oh, the assembler tests don't pass if that test is present.)

> As noted earlier, I'm seeing unwelcome behavior regardless of whether
> the test is enabled or not.  I've looked at what's going on in
> inside_entry_func() and have already determined that it's not working
> properly for me.

Andrew