Re: [rfa:symtab] deprecate inside_entry_func

[David Carlton <carlton at kealia dot com>]

On Fri, 21 Nov 2003 14:53:42 -0500, Andrew Cagney <ac131313@redhat.com> said:

>> This patch deprecates the function inside_entry_func.
>> PS: Ref:
>> http://sources.redhat.com/ml/gdb-patches/2003-10/msg00533.html

I skimmed this, though I haven't been following the discussion too
closely.  But I don't quite understand the philosophical stance here -
on the one hand, I see:

> This way all calls to inside_entry_func have been eliminated from
> up-to-date code.

which suggests that you want to get rid of the idea of
inside_entry_func(PC) entirely, but on the other hand I see:

> +   NOTE: cagney/2003-11-21: Deprecate this specific _mechanism_ for
> +   determining if the PC is inside the entry function.  While there's
> +   nothing technically wrong with the idea of using "PC inside entry
> +   function" as a condition for terminating a backtrace, there's
> +   something seriously wrong with this specific implementation.  It
> +   forces the symbol table code to go through all sorts of symbol
> +   table load and relocation hoops just to get the test right.

which suggests that you just want to get rid of the implementation.

So which is it?  It seems to me that the renaming you propose suggests
that the interface should go away, but the above comment suggests that
you're happy with the interface, you just don't like the
implementation.

If you're happy with the interface, it seems to me that the proper
thing to do is to add a big FIXME comment to inside_entry_func.  If
for some reason you think that isn't strong enough, then I could
imagine renaming it to something like "broken_inside_entry_func".  But
I don't like renaming it to deprecated_inside_entry_func if the above
NOTE is accurate.

(I don't have any opinion one way or another as to whether it's better
to deprecate the interface or to just flag the implementation as
broken.)

David Carlton
carlton@kealia.com