Re-initializing a list after the control returns to gdb...
Andrew Cagney
ac131313@redhat.com
Wed Feb 19 20:30:00 GMT 2003
>> 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.
Yes.
> 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.
That's why I used the word `observer'. When gdb-events was written (ok
when I hacked it up) I wasn't sure if it should be all (observer) or one
(as it is now).
In hindsite, it needs to be converted to an observer model (or a new
observer model introduced and the current gdb-hooks changed to one of
the many observers).
> 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?
Have a look at insight's gdb/gdbtk/generic/gdbtk-hooks.c for what it uses.
Andrew
More information about the Gdb-patches
mailing list