From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 07:06:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBAF52CE; Mon, 10 Nov 2014 07:06:17 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8365466A; Mon, 10 Nov 2014 07:06:17 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hl2so8589994igb.16 for ; Sun, 09 Nov 2014 23:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GGwzwk8AnkoaD6E8eNy7AaerIs2b5ebnzGawBJyiFTY=; b=UutL3KdA6/HAnuICGSQRxDkIUP72NJBa6KAnNrVtQbnoLqr4PO7ucJjnRHJVwzPjP1 XLsAI0Yej5mVcFq85A9Hvbh3UwbS/NUzO/Qone+p8+TrdYPhb3SYxgtjCKYQy4EtQs2B HB+S7QROou7jpEUstOH7pp2Rv+jp7siei4yTx/vDcZpv2sVlh5Y/PERZxkWNRpH/ddZe PS6gvi0C7T//YsRRkaV0FQ3QDG1a5HF0MCw2Rcs3etPocv4PPQHWekHuov+FWBZw8HDQ UFXAfHayXK9g9BHK6Zzs0uDzqFY7UDpOx4QXI+V9y3QoYve4QUwhI3Tj+XRP5a0izIxW oUTA== MIME-Version: 1.0 X-Received: by 10.50.117.104 with SMTP id kd8mr22785185igb.3.1415603176845; Sun, 09 Nov 2014 23:06:16 -0800 (PST) Received: by 10.107.19.234 with HTTP; Sun, 9 Nov 2014 23:06:16 -0800 (PST) In-Reply-To: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> Date: Sun, 9 Nov 2014 23:06:16 -0800 Message-ID: Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Shrikanth Kamath To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, 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: Mon, 10 Nov 2014 07:06:17 -0000 On Sun, Nov 9, 2014 at 10:57 AM, 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. > > -- > Rui Paulo > > > Thanks Konstantin/Rui, I did pull up this thread https://lists.freebsd.org/pipermail/freebsd-amd64/2010-June/013034.html where it was discussed, should I file a bug report? In any case I was trying to clarify that whether ET_DYN or ET_REL the offset adjustment needs to be done true or not? -- Shrikanth R K