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

[Kevin Pouget <kevin.pouget@gmail.com>]

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