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/RFC] New command: ``start''


On Wed, May 19, 2004 at 06:01:45PM -0700, Joel Brobecker wrote:
> Daniel,
> 
> On Wed, May 19, 2004 at 11:41:55AM -0400, Daniel Jacobowitz wrote:
> > On Wed, May 19, 2004 at 08:36:15AM -0700, Joel Brobecker wrote:
> > > So let's go for that route. How about:
> > >   1. I add the language-specific hook the way I designed it
> > >      in my last patch.
> > >   2. Use that hook in main_name() when the debug info didn't provide
> > >      the name of the main procedure.
> > >   3. Modify start_command to use main_name() instead of the language
> > >      hook.
> > > 
> > > Would that work for you?
> > 
> > That sounds good to me.
> 
> I was implementing this approach, with symtab.c caching the name_of_main
> so that we would compute it only once per executable loaded, but then
> just realized something that made me very uneasy.
> 
> Basically, because of the caching, we've transformed name_of_main into
> a random value, because it depends on the value of the current language
> at a certain random point in time. And that value will not be changed
> again until the user reloads his executable again (via exec-file).

You're right.  This is a problem.

> We could get rid of the caching mechanism, and recompute name_of_main
> everytime (unless found in the debug info), but I think that would be
> very costly, especially with graphical front-ends that have a tendency
> of asking for the callstack at every stop...

I don't think it would be costly.  However, I think it would be very
confusing!  Consider: we're in an Ada routine.  We backtrace.  This is
the main program, so the backtrace stops at this procedure.  We
single-step into a C subroutine and backtrace; now the backtrace goes
back to the Ada procedure and then back again further!

I'm having the same problem reviewing this that I did with
SYMBOL_SEARCH_NAME: namely, you're introducing interfaces that don't
exist in our Ada support files, without the Ada implementation of the
interface.  Could you show me what the Ada function for guessing the
name of main does?  I think the best approach may be to iterate over
the languages included in the object file, asking each of them whether
this language appears to contain a main procedure.  Or even to simply
skip the langhook complexity and just call an Ada find-main function!
For gcj I suspect we will just change the debug information.

-- 
Daniel Jacobowitz


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