From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18387 invoked by alias); 17 Nov 2011 10:06:13 -0000 Received: (qmail 18380 invoked by uid 22791); 17 Nov 2011 10:06:12 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Nov 2011 10:05:58 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAHA5uua016812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 05:05:56 -0500 Received: from springer.wildebeest.org (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pAHA5r3n032662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 05:05:54 -0500 Received: by springer.wildebeest.org (Postfix, from userid 500) id 4A74A409C3; Thu, 17 Nov 2011 11:05:53 +0100 (CET) Subject: Re: Initial stap support for inode-based uprobes From: Mark Wielaard To: David Smith Cc: Josh Stone , systemtap@sourceware.org, Srikar Dronamraju In-Reply-To: <4EC3F556.4010902@redhat.com> References: <4DD5DEAA.3050908@redhat.com> <4EC3F556.4010902@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 10:06:00 -0000 Message-ID: <1321524353.3442.22.camel@springer.wildebeest.org> Mime-Version: 1.0 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q4/txt/msg00188.txt.bz2 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