Re: Python objfile-gdb.py file -- how to handle reloading properly ?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> I'm not writing a pretty-printer, but something quite similar to
Kevin> thread-event notification (eg, thread creation/death, where some
Kevin> special locations are breakpointed, and an action is trigger upon
Kevin> hitting the bp).

Sounds cool.

Kevin> So in this case, maybe the autoloading discussed before is not
Kevin> actually the best solution. What I would like to do is:

Kevin> (at gdb startup) Load the process-independent part of my
Kevin> --python-- module

We are currently a bit weak on this part.  We should probably provide a
way for 3rd parties to drop in some Python that is loaded at startup.
I think at least the distros will want this.

Kevin> (at application startup/shared library loading) Set my
Kevin> breakpoint, resolve addresses and enable process-dependent
Kevin> commands

Loading your code can still be done via the objfile hook.  That is a
fine way to load any code associated with an objfile; the documentation
talks about pretty-printers but there is no deep connection there, and
we plan to make it more useful to load other things here (e.g., frame
filters).

It sounds like maybe what you want is to use the new event stuff to get
notifications of events.  I am not sure.  Also, because the event
support is new, there are probably things that would be useful to report
that we currently do not.  File bugs for missing stuff.

Tom