This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Python inferior control


>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> I've not changed very much: renamed the files, re-ordered the
Phil> Makefile.in and made some minor code changes so that it compiles.

Thanks for doing this.

I skimmed through it.  Some of the formatting is weird, maybe due to
wrapping in the original posts?  Anyway, be sure to fix all that up.

It still seems like a lot of code to define a new event.  But I think we
will just live with that.  Or maybe there is some way to reduce its
size, through macros or something.  There seems to be a fair amount of
boilerplate.

There are places where the error-checking is not correct.  E.g.,
emit_breakpoint_stop_event calls PyObject_CallObject but does not check
its return value.  (FWIW I think that errors in events should be
reported and then ignored -- not propagate.)

I see new attributes like "stop_eventregistry".  I think we should drop
the "registry" part of these names.

I see that all the existing event registries are on the Thread object.
I think this is fine, but I think we will also want to add more.  In
particular:

* We want some way to determine that the entire inferior has exited.
* It seems logical to want to be able to put an event handler on a
  breakpoint, to notice when that breakpoint is hit.

There are probably more of these.  I don't mind if we add them as needed
-- but it would be nice if the first release incorporating the event
machinery were complete enough to enable some "nice" scripts.

I am not sure about all of the logic in emit_stop_event.  Is this a full
enumeration of stop reasons?  Also I am unsure about python_thread_exit.
Looking at $_exitcode seems strange -- a thread doesn't really have an
exit code, only the inferior as a whole does.

One place to look for ideas here is how MI does it...


I'm afraid there will probably be more things once the above are fixed
up.  Due to the formatting and lack of docs, this patch was sort of
difficult to read.  But, I think the basics are ok.

Tom


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