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] |
> 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |