This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

using dwfl_module_build_id in systemtap


Now on the systemtap ftp site and coming soon to Fedora systems near you,
is elfutils-0.130.  This version adds support for build IDs.  These are
present in Fedora 8 builds (both in the Fedora-supplied builds and in all
normal compiles done with F8 tools) and will eventually become the norm in
all new systems with new toolchains.  

Build ID support has various good effects on finding and using separate
debuginfo files.  These are implicit just by installing the new library,
and are not especially apropros to Systemtap.

The interesting addition is dwfl_module_build_id (see libdwfl.h).  For each
given module (vmlinux, .ko, etc.) this tells you about the build ID.  It
returns 0 if there is no ID, or the length of the ID.  When there is an ID
it yields both the bitstring and the address at which those bits should
appear in the module's loaded memory image.  This address should be treated
like other addresses from libdwfl, adjusted with dwfl_module_relocate_address.

What this enables is having module code do something like:

static const unsigned char mod_kernel_id[40] __initdata = { 0xab, 0xcd, ... };

__init int module_init()	
{
	...
#define mod_kernel_id_vaddr ((void *)relocated_addr(kernel, 0x123467))
	if (memcmp(mod_kernel_id, mod_kernel_id, mod_kernel_id_vaddr))
		return -EXDEV;	/* some pithy error */
	...
}

and another such for each module whose ELF or DWARF info informed the probe
translation.  This is a very reliable way to sanity check that you really
are dealing with the target code you compiled for, before you insert kprobes.


Enjoy,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]