DTrace: stack() does not print kernel module functions for i386

[Shrikanth Kamath]

On Sun, Nov 9, 2014 at 10:57 AM, Rui Paulo <rpaulo at me.com> wrote:
> On Nov 9, 2014, at 01:36, Konstantin Belousov <kostikbel at gmail.com> 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