From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11875 invoked by alias); 7 Mar 2005 19:30:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11697 invoked from network); 7 Mar 2005 19:29:52 -0000 Received: from unknown (HELO priv-edtnes56.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 7 Mar 2005 19:29:52 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050307192951.URVH5607.priv-edtnes56.telusplanet.net@takamaka.act-europe.fr>; Mon, 7 Mar 2005 12:29:51 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5AA3947DC0; Mon, 7 Mar 2005 11:29:51 -0800 (PST) Date: Mon, 07 Mar 2005 19:30:00 -0000 From: Joel Brobecker To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Improve "start" command for Ada Message-ID: <20050307192951.GP1750@adacore.com> References: <20041021034759.GP21300@gnat.com> <01c4b72e$Blat.v2.2.2$b14feb80@zahav.net.il> <20041021210951.GZ21300@gnat.com> <20041101194703.GH27334@gnat.com> <16810.33941.938548.637890@localhost.redhat.com> <20041201030309.GE1204@adacore.com> <20050209170543.GE18540@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209170543.GE18540@adacore.com> User-Agent: Mutt/1.4i X-SW-Source: 2005-03/txt/msg00080.txt.bz2 Hello Elena, Do you think you would have some time to look at this? The review process stalled more than 3 months ago, and it would be nice to get the problem fixed. In the meantime, I will KFAIL the tests in gdb.ada that rely on the "start" command. Thanks, On Wed, Feb 09, 2005 at 12:05:43PM -0500, Joel Brobecker wrote: > Hello Elena, > > There is one part of the patch that hasn't been approved yet. I tried > to explain a bit the history of the code you were concerned with, and > I was wondering what your thoughts were. Could you have a look? (way > at the bottom of the message - I kept the rest to keep the entire > context together). > > Thanks, > -- > Joel > > > On Sun, Nov 28, 2004 at 09:08:21PM -0500, Elena Zannoni wrote: > > > Joel Brobecker writes: > > > > Ping? (doco already approved by Eli) > > > > > > > > On Thu, Oct 21, 2004 at 02:09:51PM -0700, Joel Brobecker wrote: > > > > > 2004-10-20 Joel Brobecker > > > > > > > > > > * 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. > > > > > > > > > > Tested on x86-linux. Still fixes 1 FAIL in gdb.ada/null_record.exp. > > > > > > > > > > > We need a testcase where the name of the executable is changed, and > > > this code is exercised. Otherwise ok, except for this: > > > > OK, I will add something along the line of reread.exp. > > > > > > > +/* Deduce the name of the main procedure, and set NAME_OF_MAIN > > > > > + accordingly. */ > > > > > + > > > > > +static void > > > > > +find_main_name (void) > > > > > +{ > > > > > + char *new_main_name; > > > > > + > > > > > + /* Try to see if the main procedure is in Ada. */ > > > > > + new_main_name = ada_main_name (); > > > > > + if (new_main_name != NULL) > > > > > + { > > > > > + set_main_name (new_main_name); > > > > > + return; > > > > > + } > > > > > + > > > > > + /* The languages above didn't identify the name of the main procedure. > > > > > + Fallback to "main". */ > > > > > + set_main_name ("main"); > > > > > +} > > > > > + > > > > > char * > > > > > main_name (void) > > > > > { > > > > > - if (name_of_main != NULL) > > > > > - return name_of_main; > > > > > - else > > > > > - return "main"; > > > > > + if (name_of_main == NULL) > > > > > + find_main_name (); > > > > > + > > > > > + return name_of_main; > > > > > } > > > > > > > > > > > Can this find_main_name become an element in the language vector? I > > > really don't want to have a special language cases in the symtab file. > > > > This has actually been discussed already. There were several messages > > exchanged between Daniel and myself, but here are some important ones: > > > > http://sources.redhat.com/ml/gdb-patches/2004-05/msg00607.html > > (one potential confusion if we use the *current* language vector > > to determine the name of main. This is also where the suggestion > > of calling the Ada routine directly was suggested. > > > > http://sources.redhat.com/ml/gdb-patches/2004-05/msg00612.html > > (we agree that it's ok to call ada_main_name directly) > > > > In short, the answer to the discussion was that this was probably the > > best approach for now. The reason why it can't be put in the language > > vector is that this is not a property of the language (which can vary > > within the same program, depending on the frame), but a property of > > the executable. None of us like this approach much, but it was something > > that we felt sucked the least. > > > > If you want, what we can do is replace the hard-coded call to > > ada_main_name() by a loop of calls to a new language method, > > looping on all languages until we find a positive match. That > > way, the hard wiring to Ada disappears. But I don't think we're > > getting much from this extra slight complexity. > > -- > Joel -- Joel