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. From owner-freebsd-dtrace@FreeBSD.ORG Sun Nov 9 18:57:30 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 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-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 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 From owner-freebsd-dtrace@FreeBSD.ORG Mon Nov 10 07:06:17 2014 Return-Path: Delivered-To: freebsd-dtrace@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-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: 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 From owner-freebsd-dtrace@FreeBSD.ORG Mon Nov 10 17:53:27 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 D4F3EA99; Mon, 10 Nov 2014 17:53:27 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (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 A894635D; Mon, 10 Nov 2014 17:53:27 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEU0051G4C22J40@st11p02mm-asmtp001.mac.com>; Mon, 10 Nov 2014 17:52:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-10_04:2014-11-10,2014-11-10,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-1411100133 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: Date: Mon, 10 Nov 2014 09:52:49 -0800 Content-transfer-encoding: quoted-printable Message-id: <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> To: Shrikanth Kamath X-Mailer: Apple Mail (2.1990.1) Cc: Konstantin Belousov , 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: Mon, 10 Nov 2014 17:53:27 -0000 On Nov 9, 2014, at 23:06, Shrikanth Kamath = wrote: > 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? Yes, please 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? Regarding the thread you pointed out... Maybe Andriy can clarify if he = already worked on this before. -- Rui Paulo From owner-freebsd-dtrace@FreeBSD.ORG Tue Nov 11 22:52:59 2014 Return-Path: Delivered-To: freebsd-dtrace@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 454D940B; Tue, 11 Nov 2014 22:52:59 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 47879ADF; Tue, 11 Nov 2014 22:52:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA18712; Wed, 12 Nov 2014 00:54:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XoKIo-000JGo-1P; Wed, 12 Nov 2014 00:52:46 +0200 Message-ID: <5462930B.7060907@FreeBSD.org> Date: Tue, 11 Nov 2014 14:51:55 -0800 From: Andriy Gapon User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rui Paulo , Shrikanth Kamath Subject: Re: DTrace: stack() does not print kernel module functions for i386 References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> In-Reply-To: <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@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: Tue, 11 Nov 2014 22:52:59 -0000 On 10/11/2014 09:52, Rui Paulo wrote: > On Nov 9, 2014, at 23:06, Shrikanth Kamath wrote: >> 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? > > Yes, please 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? > > Regarding the thread you pointed out... Maybe Andriy can clarify if he already worked on this before. As I recall (and the mentioned thread seems to confirm it) I encountered the problem on amd64 and I fixed it there. I never knew that there was any problem like that on other platforms including i386. This is the first time I hear about that. So, obviously I did not do any work or any testing on other platforms. Please feel free to test and fix. -- Andriy Gapon From owner-freebsd-dtrace@FreeBSD.ORG Thu Nov 13 19:23:43 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 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-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: 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 From owner-freebsd-dtrace@FreeBSD.ORG Fri Nov 14 03:49:44 2014 Return-Path: Delivered-To: freebsd-dtrace@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 0B9C8D92; Fri, 14 Nov 2014 03:49:44 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (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 D2EEB616; Fri, 14 Nov 2014 03:49:43 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NF000FP9FYFBW20@st11p02mm-asmtp001.mac.com>; Fri, 14 Nov 2014 03:49:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-14_01:2014-11-14,2014-11-13,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-1411140032 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: <201411131336.12334.jhb@freebsd.org> Date: Thu, 13 Nov 2014 19:49:27 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> <201411131336.12334.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1990.1) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, Shrikanth Kamath , avg@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: Fri, 14 Nov 2014 03:49:44 -0000 On Nov 13, 2014, at 10:36, John Baldwin wrote: > 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? No, it doesn't hurt. -- Rui Paulo From owner-freebsd-dtrace@FreeBSD.ORG Fri Nov 14 15:41:20 2014 Return-Path: Delivered-To: freebsd-dtrace@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 256A114F for ; Fri, 14 Nov 2014 15:41:20 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 74A027D6 for ; Fri, 14 Nov 2014 15:41:19 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA16813; Fri, 14 Nov 2014 17:43:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XpIzm-000MtD-FA; Fri, 14 Nov 2014 17:41:10 +0200 Message-ID: <5466225E.2050902@FreeBSD.org> Date: Fri, 14 Nov 2014 17:40:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: George Neville-Neil Subject: Re: removing solaris cyclic References: <543643A1.6030002@FreeBSD.org> <49A880FD-F346-4033-A1E5-BA1BB69FD2DA@neville-neil.com> In-Reply-To: <49A880FD-F346-4033-A1E5-BA1BB69FD2DA@neville-neil.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: 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: Fri, 14 Nov 2014 15:41:20 -0000 On 09/10/2014 18:34, George Neville-Neil wrote: > On 9 Oct 2014, at 4:13, Andriy Gapon wrote: > >> I would like to ask for a review and/or testing of the following branch >> for a phased removal of solaris cyclic code: >> https://github.com/avg-I/freebsd/compare/review/no-cyclic Raw diff: >> https://github.com/avg-I/freebsd/compare/master...review/no-cyclic.diff >> >> The only user of cyclic now is DTrace profile provider, so I am >> converting it to use our improved callout(9). cyclic is almost a >> complete implementation of an alternative to our callout(9), so having >> that big chunk of foreign code which duplicates a core function is not >> nice. >> >> One thing that I am not sure about is what PROF_ARTIFICIAL_FRAMES should >> be on different platforms. Also, I am not sure if the number of >> interrupt, timer, etc frames depends on a timer being used. I'd >> appreciate any help on this. > > Can you create a reviews.freebsd.org patch for this? Done: https://reviews.freebsd.org/D1161 -- Andriy Gapon From owner-freebsd-dtrace@FreeBSD.ORG Sat Nov 15 21:05:17 2014 Return-Path: Delivered-To: freebsd-dtrace@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 7D2F748E; Sat, 15 Nov 2014 21:05:17 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (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 55DF781C; Sat, 15 Nov 2014 21:05:17 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:53434 helo=[192.168.1.11]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XpkWu-0006F0-HP; Sat, 15 Nov 2014 16:05:14 -0500 From: "George Neville-Neil" To: "Andriy Gapon" Subject: Re: removing solaris cyclic Date: Sat, 15 Nov 2014 16:05:01 -0500 Message-ID: In-Reply-To: <5466225E.2050902@FreeBSD.org> References: <543643A1.6030002@FreeBSD.org> <49A880FD-F346-4033-A1E5-BA1BB69FD2DA@neville-neil.com> <5466225E.2050902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4576) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: 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: Sat, 15 Nov 2014 21:05:17 -0000 On 14 Nov 2014, at 10:40, Andriy Gapon wrote: > On 09/10/2014 18:34, George Neville-Neil wrote: >> On 9 Oct 2014, at 4:13, Andriy Gapon wrote: >> >>> I would like to ask for a review and/or testing of the following >>> branch >>> for a phased removal of solaris cyclic code: >>> https://github.com/avg-I/freebsd/compare/review/no-cyclic Raw diff: >>> https://github.com/avg-I/freebsd/compare/master...review/no-cyclic.diff >>> >>> The only user of cyclic now is DTrace profile provider, so I am >>> converting it to use our improved callout(9). cyclic is almost a >>> complete implementation of an alternative to our callout(9), so >>> having >>> that big chunk of foreign code which duplicates a core function is >>> not >>> nice. >>> >>> One thing that I am not sure about is what PROF_ARTIFICIAL_FRAMES >>> should >>> be on different platforms. Also, I am not sure if the number of >>> interrupt, timer, etc frames depends on a timer being used. I'd >>> appreciate any help on this. >> >> Can you create a reviews.freebsd.org patch for this? > > Done: https://reviews.freebsd.org/D1161 > Yup, reviewed. I'm hoping at least one other person on that review lists comments and if it's OK then commit it. Best, George