This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re-initializing a list after the control returns to gdb...


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]