This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python objfile-gdb.py file -- how to handle reloading properly ?
Hello,
I'm not writing a pretty-printer, but something quite similar to
thread-event notification (eg, thread creation/death, where some
special locations are breakpointed, and an action is trigger upon
hitting the bp).
So in this case, maybe the autoloading discussed before is not
actually the best solution. What I would like to do is:
> (at gdb startup) Load the process-independent part of my --python-- module
> (at application startup/shared library loading) Set my breakpoint, resolve addresses and enable process-dependent commands
-- AFAIU, that's more or less what was done with linux-thread-db.c and
libpthread.so --
whereas currently, I just load everything from the objfile-gdb.py hook
Cordially,
Kevin
On Tue, Mar 22, 2011 at 1:00 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> >>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Kevin> I'm playing with the objfile-gdb.py loading, and I can't manage to
> Kevin> support the reloading efficiently:
> [...]
> Kevin> which looks like a ugly hack! Did you find any better solution?
>
> Yeah, have your hook file be very small and have it import the real
> printers. ?The documentation lays out the best approach:
>
> ? ? ? We recommend that you put your core pretty-printers into a Python
> ? ?package. ?If your pretty-printers are for use with a library, we
> ? ?further recommend embedding a version number into the package name.
> ? ?This practice will enable GDB to load multiple versions of your
> ? ?pretty-printers at the same time, because they will have different
> ? ?names.
>
> ? ? ? You should write auto-loaded code (*note Auto-loading::) such that it
> ? ?can be evaluated multiple times without changing its meaning. ?An ideal
> ? ?auto-load file will consist solely of `import's of your printer
> ? ?modules, followed by a call to a register pretty-printers with the
> ? ?current objfile.
>
> ? ? ? Taken as a whole, this approach will scale nicely to multiple
> ? ?inferiors, each potentially using a different library version.
> ? ?Embedding a version number in the Python package name will ensure that
> ? ?GDB is able to load both sets of printers simultaneously. ?Then,
> ? ?because the search for pretty-printers is done by objfile, and because
> ? ?your auto-loaded code took care to register your library's printers
> ? ?with a specific objfile, GDB will find the correct printers for the
> ? ?specific version of the library used by each inferior.
>
> Tom