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

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

[Kevin Pouget]

Hello,

I'm playing with the objfile-gdb.py loading, and I can't manage to
support the reloading efficiently:

class my_list:
    list = []

    def addToList(elt):
        my_list.__class__.list.append(elt)

I would need this `list` attribute to keep its value across the
multiple `start` of my application, but it doesn't work this way, and
the only solution I found was:

try:
	if a is None:
		print "(exception thrown)"	
	print "second time"
except:
	print "firs timet"
	# The list of replay breakpoints
	replay_breakpoints = []
	a = 1

class my_list:
    global list

    def addToList(elt):
        list.append(elt)

which looks like a ugly hack! Did you find any better solution? ("gdb
does not track which files it has already auto-loaded this way. gdb
will load the associated script every time the corresponding objfile
is opened. So your -gdb.py file should be careful to avoid errors if
it is evaluated more than once.")


Cordially,

Kevin

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

[Kevin Pouget]

Thanks for your answer Mark

(I know I'm not very good at Python, I use it only since a few days :)

>> class my_list:
>>    list = []
>>
>>    def addToList(elt):
>>        my_list.__class__.list.append(elt)
>
> That should read 'self.list.append(elt) (and you forgot the first
> parameter 'self' to 'addToList').

actually, it's rather

@staticmethod
def addToList(elt):

that I wanted to do, that is, access a  *static* attribute

> Yes, it is quite terrible (also, don't use a bare 'except' clause). If
> you want your code to be autoloaded with your object file, have your
> script import your actual code instead (that can be installed using
> distutils). Modules are cached, so it will only be imported once.

what would you think about caching the already-loaded module list, and
allowing them to register a callback?
That's for instance what is done in `linux-thread-db.c` to detect the
loading of the libpthread.so, and that's pretty much what I would like
to do.

(I mean, if you guys feel like it's an interesting feature but no one
fancies doing it, I could give it a try)

> Although not related directly to your problem, I suggest reading
> docs.python.org/tut.

will do, thanks



Kevin

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

[Tom Tromey]

>>>>> "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

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

[Kevin Pouget]

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

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

[Kevin Pouget]

symbolic breakpoints would solve half of my problem, I still need to
lookup some global variable addresses when my library has been loaded,
so that I can read the right memory and understand the meaning of my
breakpoint hit


thanks for sharing cydbg, it's always good to have some working examples !

On Wed, Mar 23, 2011 at 6:06 AM, mark florisson
<markflorisson88@gmail.com> wrote:
> On 23 March 2011 11:01, mark florisson <markflorisson88@gmail.com> wrote:
>> On 23 March 2011 10:05, Kevin Pouget <kevin.pouget@gmail.com> wrote:
>>> 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
>>
>> You can set (symbolic) breakpoints even before your shared library is
>> loaded ('set breakpoint pending on').
>>
>> If you want to provide process independent functionality, create a
>> Python wrapper script that starts gdb and has it import the
>> process-independent code. If you need some inspiration, you could take
>> a look at this:
>> https://github.com/markflorisson88/cython/blob/master/Cython/Debugger/Cygdb.py
>> . It writes gdb commands to a tempfile and then loads gdb which reads
>> the commands from the tempfile.
>
> In fact, if you don't have multi-line commands, you can simply use
> gdb's -ex option: gdb -ex 'python import mymodule'
>
>> Good luck!
>>
>> Mark
>>
>

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

[Tom Tromey]

>>>>> "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