From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2538 invoked by alias); 19 Feb 2003 02:01:04 -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 2531 invoked from network); 19 Feb 2003 02:01:03 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by 172.16.49.205 with SMTP; 19 Feb 2003 02:01:03 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 3AF7BD34B6; Tue, 18 Feb 2003 18:01:02 -0800 (PST) Date: Wed, 19 Feb 2003 02:01:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re-initializing a list after the control returns to gdb... Message-ID: <20030219020101.GI2105@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00394.txt.bz2 Hello, I am trying to do a small cleanup in our ada-tasks module, and I was wondering if somebody could help me making sure I am using the right approach. Basically: the ada_language provides a set of commands, namely "info tasks" and "task". Here is the syntax: - info tasks -> prints the list of tasks, equivalent of "info threads" - info tasks -> the detailed information on a given task - task -> print the current task id, equivalent of "thread" - task -> switch to the given task The small annoyance I am trying to fix is that all these commands use a list internally maintained in ada-tasks.c, which gets built only when the "info tasks" command is called. So far, we have documented that the above command may only be used after "info tasks" has been issued. What I am trying to do is to lift this limitation, by updating the list of tasks every time the user has resumed the execution of the inferior, just before the user gets back the prompt. I did it by inserting a call to ada_reset_tasks_list() inside normal_stop(), like so: *************** print_stop_reason (enum inferior_stop_re *** 3360,3365 **** --- 3362,3369 ---- void normal_stop (void) { + ada_reset_tasks_list (NULL); + /* As with the notification of thread events, we want to delay notifying the user that we've switched thread context until the inferior actually stops. My testing shows that it seems to be working pretty well. But do you think that this is a good idea? And does this change have any chance of being accepted for inclusion (eventually, we are still ironing out some wrinkles here and there to make our changes more acceptable, but hope to be able to contribute our ada-language support changes soon)? -- Joel