Re: [RFA/RFC] New command: ``start''

[Joel Brobecker <brobecker at gnat dot com>]

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

That could lead to situations where the wrong value for name_of_main
is computed. Consider the following example:

   The user has an Ada program. Like every program, it has some bits
   and pieces that are not Ada. It could be a multi-language application
   but also an Ada program linked to the libc. Anyway, he inserts a
   breakpoint inside some non-Ada routine, does a "run", then a
   backtrace => we set "name_of_main" in symtab.c using the non-ada
   language vector => name_of_main will likely be wrong.

   At this point, GDB will unwind up to the wrong frame (one frame
   too high in case of Ada programs), but even more problematic is
   the fact that the "start" command will stop at the wrong place.
   And forcing the language to Ada won't help.
   
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...

We could try to make it a little smarter, by recomputing the
name_of_main if the value we previously computed was for a different
language. I think that we will still end up recomputing it fairly often
as callstacks involving more than one language can be fairly common.

Or another better approach, is to store an array of name_of_main, one
per language, and then get main_name() to return the correct one based
on the language given to it. That way, we only compute it once per
language (will usually be once or twice per session, three times at
most, I would anticipate). Unfortunately, this raises the same sort
of issues, because there will be times when we call main_name() with
the idea of getting the main program name from the user's point of
view, and we will simply not know which language to select for that.

Or the last approach would be to leave main_name() alone, and make
the "start" command independent of that mechanism (my initial approach).

Computing the main name lazily and caching sounds like a perfect receipe
for incorrect behavior. So I think we have two possible alternatives at
this stage:
  
  . Recompute name_of_main every time (big performance penalty I think)

  . Dissociate the "start" command infrastructure from the
    name_of_main() infrastructure, and keep my initial approach.

I know you would like to avoid having several mechanisms computing the
name of main, but I think this is our best alternative in this case.

What do you think? I am attaching a patch to symtab.c just to illustrate
what I was trying to do.

-- 
Joel

Attachment: symtab.c.diff
Description: Text document