Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
dyndbg: try DEFINE_DYNAMIC_DEBUG_TABLE
Test DEFINE_DYNAMIC_DEBUG_TABLE, in i915.ko, by adding an invocation into i915_drv.c, the 1st object built in the Makefile. This does manually what can perhaps be done transparently in headers (hopefully). DEFINE_DYNAMIC_DEBUG_TABLE is based on DEFINE_DYNAMIC_DEBUG_METADATA; just like its model, it creates a pair of structs: _ddebug & _ddebug_callsite, and inits them with format="0000", lineno=0. This: - identifies it clearly in control output - appears to place it 1st in the section(s) it works here, at least for modprobed module 1st-to-build might be the real reason for the sort. drivers/gpu/drm/i915/i915_drv.c:0 [i915](null) =_ "0000" drivers/gpu/drm/i915/gvt/gvt.c:437 [i915]intel_gvt_register_hypervisor =_ "gvt: core: Running with hypervisor %s drivers/gpu/drm/i915/gvt/gvt.c:378 [i915]intel_gvt_init_device =_ "gvt: core: gvt device initialization is done\0 other big diff between DEFINE_DYNAMIC_DEBUG_TABLE/_METADATA: - not static decls. removing static made the line appear in control output (below). (cuz it might be reffd elsewhere, so its linked). we want this. it also needs to be visible where DEFINE_DYNAMIC_DEBUG_METADATA is used, so it can be used to initialize .module_index, ie in many other objects where pr_debugs are coded. A peek inside i915_drv.o looks about right; i915_site is expected at least. Relocation section '.rela__dyndbg' at offset 0x6f48 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000010 014c00000001 R_X86_64_64 0000000000000000 i915_site + 0 000000000018 001a00000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 548 Relocation section '.rela__dyndbg_callsites' at offset 0x6f90 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 001a00000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + d8 000000000008 000a00000001 R_X86_64_64 0000000000000000 .rodata.str1.8 + 110 Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
- Loading branch information