From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18657 invoked by alias); 19 Feb 2003 19:24:25 -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 18640 invoked from network); 19 Feb 2003 19:24:24 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by 172.16.49.205 with SMTP; 19 Feb 2003 19:24:24 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id CDA16D34B6; Wed, 19 Feb 2003 11:24:22 -0800 (PST) Date: Wed, 19 Feb 2003 19:24:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: Re-initializing a list after the control returns to gdb... Message-ID: <20030219192422.GS2105@gnat.com> References: <20030219020101.GI2105@gnat.com> <3E53B97A.4090809@redhat.com> <20030219175056.GP2105@gnat.com> <3E53C88E.90807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E53C88E.90807@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00433.txt.bz2 > The code relies on global state so I think `target changed' is better - > that way you know that your state is up-to-date. From memory, right now > we've actually memory_changed and registers_changed (I think they should > be merged). There is also a target run hook that insight uses. Unfortunately `target changed' does not trigger at least every time I need it to. I looked at the code, and it should basically trigger everytime we change some data in memory. A quick attempt with "set debug event 1" shows that the only events I see in a simple "break; run" sequence are breakpoint events... > That's the problem (you said sick), we've three: > - gdb-events > - chained hooks > - simple hooks > gdb-events started on the problem but lost direction. I like the events mechanism, it's a paradigm that's used very widely. But the gdb-event mechanism does not seem to allow several clients subscribing for these events at the same time. This mechanism is then very close to the simple hooks. I am therefore thinking of implementing a new chained hook in place of the direct call to ada_read_tasks_list. Would that be an acceptable solution? -- Joel