This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: container_of equivalent in gdb-python script
On Wed, Jun 10, 2009 at 10:10:39PM +0200, Jan Kiszka wrote:
> I want to automate 'add-symbol-file linux_module.ko 0xff...' that you
> have to run for loading the symbols of dynamically loaded kernel
> modules. Before that you also have to look up the module base address,
> typically by cat'ing /proc/modules on the target. With a proper python
> script, this will be trivial to do automatically. You just have to walk
> the module list of the kernel you are attached to, extract names and
> base addresses, search for the corresponding module binaries (also easy
> with python) and issue the proper add-symbol-file commands.
FYI, I am hoping to work on this soon (in the next month). The right
representation is not a set of add-symbol-file commands, which doesn't
play nicely with repeated unload/reload, but instead a synthetic list
of shared libraries. That calls for some extensions to the current
set of Python hooks and shared library infrastructure, though! And it
will require basically everything you're doing now :-)
> But now back to the core problems, starting with the exercise to
> implement offset_of(type, field):
>
> def offset_of(type, field):
> container_type = gdb.lookup_type(type)
> dummy_obj = gdb.selected_frame().read_var('modules')
> container_obj = dummy_obj.cast(container_type)
> field_obj = container_obj[field]
> return int(str(field_obj.address), 16) - \
> int(str(container_obj.address), 16)
>
> I meanwhile discovered (reading testcases and python-*.c)
> gdb.lookup_type() and Value.cast() to make this real. But you see, I
> still need an ugly synthetic Value object which must have a non-'None'
> address to do this calculation. Is there a cleaner, more generic way?
It's typical to do this the same way folks do in C: Create a null
pointer of the right type.
--
Daniel Jacobowitz
CodeSourcery