This is the mail archive of the 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: plan for python inferiors, threads, and events

El jue, 05-03-2009 a las 13:05 -0300, Thiago Jung Bauermann escribiÃ:
> El vie, 12-12-2008 a las 12:11 -0700, Tom Tromey escribiÃ:
> > * It ought to keep working once gdb moves to multi-process.  E.g., the
> >   current "gdb.threads" stuff is not super in this regard (IMO).
> I agree, but I believe that single-process debugging sessions will be
> more common than multi-process ones. Because of this, IMHO we should
> provide a way for users to write scripts and python code snippets
> without having to worry about multi-process issues. Cases in point are
> the caller_is and in_scope convenience functions.

Take, for instance, the gdb.{read,write,search}_memory functions. They
should be methods in the gdb.Inferior class. But if we keep them as
functions in the gdb module, and have them mean "do these actions in the
current and/or selected inferior", we save a lot of people from having
to type gdb.selected_inferior (). Ithink this would avoid some of the
Java silliness of having to call big strings of methods to get what you

For the cases where the actual inferior matters, one can call
gdb.selected_inferior, or go thorugh a list from gdb.inferiors.

A similar argument can be made about threads (so we would keep
gdb.frames and gdb.{current,selected}_frame) to save one call to
gdb.{current,selected}_thread. I think gdb.selected_frame can be kept
regardless, since there's only one selected frame even in multi-threaded
apps, IIRC.


> > class gdb.InferiorThread
> >   Right now, no methods.

There'll be the frames method.
Thiago Jung Bauermann
IBM Linux Technology Center

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