From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 19:23:43 2014 Return-Path: Delivered-To: freebsd-hackers@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 19E80731; Thu, 13 Nov 2014 19:23:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E445F9E1; Thu, 13 Nov 2014 19:23:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB005B94F; Thu, 13 Nov 2014 14:23:41 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: DTrace: stack() does not print kernel module functions for i386 Date: Thu, 13 Nov 2014 13:36:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> In-Reply-To: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411131336.12334.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Nov 2014 14:23:41 -0500 (EST) Cc: Konstantin Belousov , avg@freebsd.org, Shrikanth Kamath , freebsd-dtrace@freebsd.org, Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:23:43 -0000 On Sunday, November 09, 2014 1:57:19 pm Rui Paulo wrote: > On Nov 9, 2014, at 01:36, Konstantin Belousov wrote: > > > > 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. > > I agree with your analysis. I think this patch should go in with the #ifdef __amd64__ for ET_REL. > Why have the #ifdef? In theory other platforms besides amd64 could use sys/kern/link_elf_obj.c. It doesn't hurt to just let the code always accept both ET_DYN and ET_REL does it? -- John Baldwin