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

[Andrew Cagney <cagney@gnu.org>]

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