This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa:symtab] deprecate inside_entry_func


On Oct 31,  9:27pm, Andrew Cagney wrote:

> > Kevin, you previously wrote:
> > 
> >> >> 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.
> > 
> > 
> > Yes, the reason I wrote this was to note that there are other ways of
> > implementing inside_entry_func() which wouldn't place garish
> > requirements on the object file readers.
> 
> Then I'm puzzled as to why you are objecting to me deprecating this 
> existing garish hack?  Remember, I also wrote:
> 
>  > +  /* NOTE: cagney/2003-10-31: A very simple test, such as
>  > +     get_frame_func == entry_point should be sufficient for
>  > +     identifying a pc in the entry function.  Does anyone know why it
>  > +     wasn't sufficient and hence, why the very convoluted
>  > +     "deprecated_inside_entry_func" is needed.  */

What I'm suggesting is that you implement inside_entry_func() using
"get_frame_func == entry_point".  What's so garish about that?

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]