From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 18:57:30 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 9634A678; Sun, 9 Nov 2014 18:57:30 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69261A5C; Sun, 9 Nov 2014 18:57:29 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NES002KJCNKDM20@st11p02mm-asmtp002.mac.com>; Sun, 09 Nov 2014 18:57:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-09_03:2014-11-07,2014-11-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411090178 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Rui Paulo In-reply-to: <20141109093632.GV53947@kib.kiev.ua> Date: Sun, 09 Nov 2014 10:57:19 -0800 Content-transfer-encoding: quoted-printable Message-id: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> References: <20141109093632.GV53947@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-dtrace@freebsd.org, freebsd-hackers@freebsd.org, Shrikanth Kamath , avg@freebsd.org 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: Sun, 09 Nov 2014 18:57:30 -0000 On Nov 9, 2014, at 01:36, Konstantin Belousov = wrote: >=20 > 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). >>=20 >> 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 >>=20 >> @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct = kld_fil >> #if defined(__FreeBSD__) >> mapbase =3D (uintptr_t)k_stat->address; >> gelf_getehdr(dmp->dm_elf, &ehdr); >> - is_elf_obj =3D (ehdr.e_type =3D=3D ET_REL); >> + is_elf_obj =3D (ehdr.e_type =3D=3D ET_REL) || (ehdr.e_type =3D=3D= ET_DYN); >> if (is_elf_obj) { >> dmp->dm_sec_offsets =3D >> malloc(ehdr.e_shnum * = sizeof(*dmp->dm_sec_offsets)); >>=20 >> 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 >>=20 >> 0 50825 pmc_find_process_descriptor:entry >> 0xc3c35bf5 <-- Address >> not matched to symbol >> kernel`syscall+0x48b >> kernel`0xc0fd2121 >>=20 >> whereas with the above nit change to include ET_DYN for section = offset >> adjustment I get the complete stack trace as >>=20 >> 0 50825 pmc_find_process_descriptor:entry >> hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to = symbol >> kernel`syscall+0x48b >> kernel`0xc0fd2121 >>=20 >> 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 >>=20 >> 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) >>=20 >> because dml->dm_text_va was not setup correctly in dt_module_update. >>=20 >> Can somebody help clarify this? >>=20 >> Reference: commit revision 210425. >=20 > I have no idea about DTrace guts, but can add one note you might find > useful. >=20 > =46rom 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. >=20 > 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. -- Rui Paulo