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

[Joel Brobecker <brobecker at gnat dot com>]

> So, can you get a prototype observer working for just your ada event 
> (but keep in mind that other events will be boiler-plated)?
> 
> As for the names, just use the terminology found in the patterns book - 
> observer.[hc].  observer_update_xxx (or notify_xxx), 
> observer_attach_xxx, observer_detach_xxx I think.  If GDB needs more 
> than one observer, there's a problem.

Attached is a prototype that appears to be working. I assumed that you
had in mind an approach were the exported interface is nice and clean
and the implementation uses an underlying generic mechanism with
nasty casts and marshalling/unmarshalling.

While looking more closely at gdb-events, I understood better your
comment about doco and gdbarch.sh. I think that with the current
prototype, it should be relatively easy to generate observer.[hc].

There was another approach that came to my mind when I realized that
observer.[hc] could be generated by a script: instead of using a
internal generic observer, we could simply duplicate the code for
each external observer... Although it does avoid the type casting et al,
I discarded this approach as a bit too brutal and not very elegant. 

I tested this code by using a little test program. I will try not to
forget to attach it. Would there be any way to build this program or
some equivalent somewhere in our testsuite? My (very limited) first test
was also inside GDB itself, where I added a ada-tasks as an observer for
the normal_stop notification, and added a call to
observer_notify_normal_stop in normal_stop.

About the struct observer: the data field is currently used to hold the
pointer to the real observer notification function. So there is no
deallocation issue for now. I tried to make it clear that no
deallocation mechanism has been put in place for this field by adding a
comment next to the field declaration. It can later be extended to also
hold some context data, if needed. However, if/when this happens, we'll
have to extend the attach routine to accept 2 new parameters: a pointer
to the context data, a pointer to a function to deallocate this data.

I also have to admit upfront that choosing names has always been one
of my big weaknesses. I warmly welcome suggestions.

One last thing, I omitted the copyright headers for now. I'll make sure
to add them when I submit the RFA.

> (oh, unless you've an immediate need for that data/context parameter, 
> i'd leave it out - such a mechanis can be left to the person that 
> actually needs)

Cools, that saves a bit of complexity for later, although there isn't
much more needed.

> (shh, doco - but I have a cunning plan - see my recent post about 
> revamping gdbarch.sh into doc/gdbarch.texi).

Right, I will add the proper documentation too. Ideally, having the doco
in an observer.sh script would be great.

-- 
Joel

Attachment: observer.h
Description: Text document

Attachment: observer.c
Description: Text document

Attachment: test_observer.c
Description: Text document