#
284085 |
|
06-Jun-2015 |
markj |
libdtrace: allow D libraries to declare dependencies on kernel modules
The "depends_on module" pragma can be used to declare a dependency on a DTrace module, which for kernel probes corresponds to a KLD. Such dependencies cannot be checked if the KLD is compiled into the kernel. Therefore, allow a module dependency to be satisfied if either a kernel module or a KLD with the specified name is loaded.
Differential Revision: https://reviews.freebsd.org/D2653 Reviewed by: gnn, rpaulo Reported by: gnn
|
#
275011 |
|
25-Nov-2014 |
markj |
The module load address always needs to be included when setting the dm_*_va fields of dt_module_t. Previously, this was only done on architectures where kernel modules have type ET_REL; this change fixes that. As a result, symbol name resolution in the stack() action now works properly for kernel modules on i386.
Reported by: Shrikanth Kamath <shrikanth07@gmail.com> Tested by: Shrikanth Kamath Discussed with: avg MFC after: 2 weeks
|
#
210425 |
|
23-Jul-2010 |
avg |
dtrace: correctly map sections to addresses in elf object modules (amd64)
Unlike for modules with dso type, in elf object modules all the sections have virtual address of zero. So, it is insufficient to add module base address to section virtual address (as recorded in section header) to get section address in kernel memory. Instead, we should apply the same calculations that are performed by kernel loaders (in boot code and in kernel) when they lay out sections in memory. Also, unlike OpenSolaris, the sections are not collapsed into just .text, .data and .bss by module loaders, so we need to take additional care about other sections.
Note that in-kernel symbol-to-address mapping worked just fine, e.g. fbt provider could correctly find the functions, etc. It's only in userland that the mapping in both direction worked incorrectly, e.g. in stack() output addresses of functions in kernel modules were not translated to their names.
Reviewed by: rpaulo MFC after: 3 weeks
|