From owner-freebsd-dtrace@FreeBSD.ORG Sun Nov 9 09:36:38 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DD0B44E; Sun, 9 Nov 2014 09:36:38 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30C8F2A6; Sun, 9 Nov 2014 09:36:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA99aWQe042257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2014 11:36:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA99aWQe042257 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA99aWVq042256; Sun, 9 Nov 2014 11:36:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Nov 2014 11:36:32 +0200 From: Konstantin Belousov To: Shrikanth Kamath Subject: Re: DTrace: stack() does not print kernel module functions for i386 Message-ID: <20141109093632.GV53947@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, avg@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:36:38 -0000 On Sat, Nov 08, 2014 at 02:06:39PM -0800, Shrikanth Kamath wrote: > I verified this on a FreeBSD 10.0 STABLE, the stack() feature does not > appear to print functions from kernel modules. I believe there is a > glitch in libdtrace in the function "dt_module_update" > (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). > > The section header address computation which is currently being done > in the function dt_module_update for elf type ET_REL, a similar > computation needs to be done for the ET_DYN maybe. I lack background > on the elf types but for experiment sakes I changed the line > > @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_fil > #if defined(__FreeBSD__) > mapbase = (uintptr_t)k_stat->address; > gelf_getehdr(dmp->dm_elf, &ehdr); > - is_elf_obj = (ehdr.e_type == ET_REL); > + is_elf_obj = (ehdr.e_type == ET_REL) || (ehdr.e_type == ET_DYN); > if (is_elf_obj) { > dmp->dm_sec_offsets = > malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); > > So from a previous run where I was running a dtrace one liner > %dtrace -n 'fbt:hwpmc:: { stack(); }' > The output without the above change shows a sample as > > 0 50825 pmc_find_process_descriptor:entry > 0xc3c35bf5 <-- Address > not matched to symbol > kernel`syscall+0x48b > kernel`0xc0fd2121 > > whereas with the above nit change to include ET_DYN for section offset > adjustment I get the complete stack trace as > > 0 50825 pmc_find_process_descriptor:entry > hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to symbol > kernel`syscall+0x48b > kernel`0xc0fd2121 > > I believe without the correct section offset adjustment the following > check in the function dtrace_lookup_by_addr fails to match the address > to the correct symbol > > if (addr - dmp->dm_text_va < dmp->dm_text_size || > addr - dmp->dm_data_va < dmp->dm_data_size || > addr - dmp->dm_bss_va < dmp->dm_bss_size) > > because dml->dm_text_va was not setup correctly in dt_module_update. > > Can somebody help clarify this? > > Reference: commit revision 210425. I have no idea about DTrace guts, but can add one note you might find useful. >From the backtace above I can conclude that your platform is i386. A difference between i386 and amd64 is that i386 modules are dso's (ET_DYN), while on amd64 modules are only linked to object files (ET_REL). The original author of the code probably tested on amd64. You may want to special case amd64 by #ifdef, and use ET_DYN on other arches.