Date: Sun, 09 Nov 2014 10:57:19 -0800 From: Rui Paulo <rpaulo@me.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-dtrace@freebsd.org, freebsd-hackers@freebsd.org, Shrikanth Kamath <shrikanth07@gmail.com>, avg@freebsd.org Subject: Re: DTrace: stack() does not print kernel module functions for i386 Message-ID: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> In-Reply-To: <20141109093632.GV53947@kib.kiev.ua> References: <CAEOAkMXnwqC42gZKc0f80cppff077pYGjs5PUPht0DBcyEi8Jw@mail.gmail.com> <20141109093632.GV53947@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 9, 2014, at 01:36, Konstantin Belousov <kostikbel@gmail.com> =
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9011F920-3092-4E61-9CDC-68FD9092BB7D>