From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12737 invoked by alias); 10 Jun 2009 20:42:12 -0000 Received: (qmail 12724 invoked by uid 22791); 10 Jun 2009 20:42:11 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 20:42:05 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2C48810738; Wed, 10 Jun 2009 20:42:03 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id E1CFF10728; Wed, 10 Jun 2009 20:42:02 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MEUcT-0004nO-Mt; Wed, 10 Jun 2009 16:42:01 -0400 Date: Wed, 10 Jun 2009 20:42:00 -0000 From: Daniel Jacobowitz To: Jan Kiszka Cc: tromey@redhat.com, gdb@sourceware.org Subject: Re: container_of equivalent in gdb-python script Message-ID: <20090610204201.GA17154@caradoc.them.org> Mail-Followup-To: Jan Kiszka , tromey@redhat.com, gdb@sourceware.org References: <4A2FE5AB.4060707@siemens.com> <4A30133F.9000909@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A30133F.9000909@web.de> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00097.txt.bz2 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