Re: [RFA] Improve "start" command for Ada

[Joel Brobecker <brobecker@adacore.com>]

Just to confirm that I just checked in the following patch:

2005-03-07  Joel Brobecker  <brobecker@adacore.com>

        * doc/observer.texi (executable_changed): New observer.
        * symtab.c: Include "observer.h".
        (find_main_name): New function.
        (main_name): If name_of_main is unset, then compute it
        using find_main_name.
        (symtab_observer_executable_changed): New function.
        (_initialize_symtab): Attach executable_changed observer.
        * exec.c: Include "observer.h".
        (exec_file_attach): Emit executable_changed notification.
        * symfile.c: Include "observer.h".
        (reread_symbols): Send an executable_changed if appropriate.
        * Makefile.in (exec.o): Add dependency on observer.h.
        (symfile.o): Likewise.
        (symtab.o): Likewise.

This fixes the following 2 FAILs:

        FAIL: gdb.ada/null_record.exp: start (PRMS ada/1892)
        FAIL: gdb.ada/start.exp: start (PRMS ada/1892)

Here is the comment that I added:

  /* FIXME: brobecker/2005-03-07: Another way of doing this would
     be to add a new method in the language vector, and call this
     method for each language until one of them returns a non-empty
     name.  This would allow us to remove this hard-coded call to
     an Ada function.  It is not clear that this is a better approach
     at this point, because all methods need to be written in a way
     such that false positives never be returned. For instance, it is
     important that a method does not return a wrong name for the main
     procedure if the main procedure is actually written in a different
     language.  It is easy to guaranty this with Ada, since we use a
     special symbol generated only when the main in Ada to find the name
     of the main procedure. It is difficult however to see how this can
     be guarantied for languages such as C, for instance.  This suggests
     that order of call for these methods becomes important, which means
     a more complicated approach.  */

-- 
Joel