This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Initial stap support for inode-based uprobes
- From: Mark Wielaard <mjw at redhat dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: Josh Stone <jistone at redhat dot com>, systemtap at sourceware dot org, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Date: Thu, 17 Nov 2011 11:05:53 +0100
- Subject: Re: Initial stap support for inode-based uprobes
- References: <4DD5DEAA.3050908@redhat.com> <4EC3F556.4010902@redhat.com>
On Wed, 2011-11-16 at 11:39 -0600, David Smith wrote:
> > * Runtime build-id verification. Right now I'm just mapping the path to
> > inode*, without checking that the build-id is what we expected. I'm not
> > sure we even could at the systemtap-init point. Even if we did, the
> > file may still get modified without changing the inode, and I don't
> > think this uprobes gives us any way to notice or decide whether we like
> > the new form.
I am not sure where this exactly is/should be done, or how/why the inode
pointed to can still change. But if the inode points to an ELF file,
then it shouldn't be too hard to get at the build-id.
You have to parse the elf header, get at the program headers (e_phoff),
iterate over them (e_phentsize) till you find the one that is marked
with PT_NOTE, and then parse all notes till you get the one with the
right type (NT_GNU_BUILD_ID) and name ("stapsdt")
OK, so it is somewhat involved. But assuming we are in user context when
we get at the inode and the inode represents an ELF file we can parse,
then that would actually be nicer than what we currently do by
extracting the offset to the note directly and peeling it out through
that offset.
Cheers,
Mark