From: Jim Cromie <jim.cromie@gmail.com>
To: jbaron@akamai.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org
Cc: Jim Cromie <jim.cromie@gmail.com>
Subject: [RFC PATCH v6 20/34] dyndbg: RFC handle __dyndbg* sections in module.lds.h
Date: Sat, 29 May 2021 14:00:15 -0600 [thread overview]
Message-ID: <20210529200029.205306-21-jim.cromie@gmail.com> (raw)
In-Reply-To: <20210529200029.205306-1-jim.cromie@gmail.com>
Up until now, loadable modules have tacitly linked the 2 __dyndbg*
sections into the .ko, as observable in log by enabling module.c's
pr_debugs and loading a module.
But now, we need to explicitly compose our named output sections,
placing the header sections in front of their respective __dyndbg*
input sections. We reuse input section names for the output.
This gives us the placement we need for the header record, which we
can see in the "add-module:"s and elements "0 0" below:
"0 0" lines are headers: predicate (function==module && !lineno)
"X debug prints in" are 1 too high, they count headers.
we are adding tables for empty modules (1st 2 below)
[ 7.578873] dyndbg: add-module: ghash_clmulni_intel
[ 7.579716] dyndbg: 0 0 ghash_clmulni_intel.ghash_clmulni_intel.0
[ 7.608995] dyndbg: 1 debug prints in module ghash_clmulni_intel
[ 8.078085] dyndbg: add-module: rapl
[ 8.078977] dyndbg: 0 0 rapl.rapl.0
[ 8.079584] dyndbg: 1 debug prints in module rapl
[ 8.082009] RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer
[ 8.099294] dyndbg: add-module: intel_rapl_common
[ 8.100177] dyndbg: 0 0 intel_rapl_common.intel_rapl_common.0
[ 8.101026] dyndbg: 1 1 intel_rapl_common.rapl_remove_package.1279
[ 8.101931] dyndbg: 2 2 intel_rapl_common.rapl_detect_domains.1245
[ 8.102836] dyndbg: 3 3 intel_rapl_common.rapl_detect_domains.1242
[ 8.103778] dyndbg: 4 4 intel_rapl_common.rapl_package_register_powercap.1159
[ 8.104960] dyndbg: 5 5 intel_rapl_common.rapl_package_register_powercap.1145
[ 8.106246] dyndbg: 6 6 intel_rapl_common.rapl_package_register_powercap.1114
[ 8.107302] dyndbg: 7 7 intel_rapl_common.rapl_package_register_powercap.1108
[ 8.108338] dyndbg: 8 8 intel_rapl_common.rapl_update_domain_data.1083
[ 8.109278] dyndbg: 9 9 intel_rapl_common.rapl_check_unit_atom.824
[ 8.110255] dyndbg: 10 10 intel_rapl_common.rapl_check_unit_core.796
[ 8.111361] dyndbg: 11 11 intel_rapl_common.rapl_read_data_raw.722
[ 8.112301] dyndbg: 12 12 intel_rapl_common.contraint_to_pl.303
[ 8.113276] dyndbg: 13 debug prints in module intel_rapl_common
[ 8.130452] dyndbg: add-module: intel_rapl_msr
[ 8.131140] dyndbg: 0 0 intel_rapl_msr.intel_rapl_msr.0
[ 8.132026] dyndbg: 1 1 intel_rapl_msr.rapl_msr_probe.172
[ 8.132818] dyndbg: 2 2 intel_rapl_msr.rapl_msr_read_raw.104
[ 8.133794] dyndbg: 3 debug prints in module intel_rapl_msr
This gives us the property we need:
fixed offset from &__dyndbg[N] to &__dyndbg[0]
container_of gets &header
header has ptr to __dyndbg_sites[]
we can (in principle) drop __dyndbg.site ptr
(after we adapt header to keep it)
TODO:
At this point, for loaded modules, ddebug_add_module() sees the header
as 0'th element, as we need in order to drop site (and regain worst
case footprint parity).
It could/should properly init this header to support the _sites[n]
lookup for loaded mods. Or at least handle it explicitly. Or at
least see what proc-show does with it currently.
Note that for builtins, decided by (__start <= dp < __stop), we use
__start___dyndbg_sites[N] directly, and dont need the header.
But maybe we should use it anyway, double-checking/BUGing when wrong.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
include/asm-generic/module.lds.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/module.lds.h b/include/asm-generic/module.lds.h
index f210d5c1b78b..70e744c953f5 100644
--- a/include/asm-generic/module.lds.h
+++ b/include/asm-generic/module.lds.h
@@ -4,7 +4,14 @@
/*
* <asm/module.lds.h> can specify arch-specific sections for linking modules.
- * Empty for the asm-generic header.
+ *
+ * Normally, sections get thru tacitly, but for CONFIG_DYNAMIC_DEBUG,
+ * we need to insert the .gnu.linkonce sections into the output
+ * sections, so we have to say everything explicitly.
*/
+SECTIONS {
+__dyndbg_sites : ALIGN(8) { *(.gnu.linkonce.dyndbg_site) *(__dyndbg_sites) }
+__dyndbgs : ALIGN(8) { *(.gnu.linkonce.dyndbg) *(__dyndbgs) }
+}
#endif /* __ASM_GENERIC_MODULE_LDS_H */
--
2.31.1
next prev parent reply other threads:[~2021-05-29 20:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 19:59 [RFC PATCH v6 00/34] DYNAMIC_DEBUG diet progress, dropped 30kb Jim Cromie
2021-05-29 19:59 ` [RFC PATCH v6 01/34] dyndbg: avoid calling dyndbg_emit_prefix when it has no work Jim Cromie
2021-05-29 19:59 ` [RFC PATCH v6 02/34] dyndbg: drop uninformative vpr_info Jim Cromie
2021-05-29 19:59 ` [RFC PATCH v6 03/34] dyndbg: display KiB of data memory used Jim Cromie
2021-05-29 19:59 ` [RFC PATCH v6 04/34] dyndbg: split struct _ddebug's display fields to new _ddebug_site Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 05/34] dyndbg: __init iterate over __dyndbg & __dyndbg_site in parallel Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 06/34] dyndbg+module: expose ddebug_sites to modules Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 07/34] dyndbg: refactor part of ddebug_change to ddebug_match_site Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 08/34] dyndbg: accept null site in ddebug_match_site Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 09/34] dyndbg: hoist ->site out of ddebug_match_site Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 10/34] dyndbg: accept null site in ddebug_change Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 11/34] dyndbg: accept null site in dynamic_emit_prefix Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 12/34] dyndbg: accept null site in ddebug_proc_show Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 13/34] dyndbg: refactor ddebug_alter_site out of ddebug_change Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 14/34] dyndbg: allow deleting site info via control interface Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 15/34] dyndbg: add ddebug_site(_get|_put) abstraction Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 16/34] dyndbg: ddebug_add_module avoid adding empty modules Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 17/34] dyndbg: add _index to struct _ddebug Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 18/34] dyndbg: prevent build bugs via -DNO_DYNAMIC_DEBUG_TABLE Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 19/34] dyndbg: RFC - DEFINE_DYNAMIC_DEBUG_TABLE Jim Cromie
2021-05-29 20:00 ` Jim Cromie [this message]
2021-05-29 20:00 ` [RFC PATCH v6 21/34] dyndbg: ddebug_add_module() handle headers Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 22/34] dyndbg: validate ddebug_site_get invariants Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 23/34] dyndbg: fix NULL deref after deleting sites Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 24/34] dyndbg: dont show header records in control Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 25/34] dyndbg: make site pointer and checks on it optional (almost) Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 26/34] dyndbg: swap WARN_ON for BUG_ON see what 0-day says Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 27/34] dyndbg: fixup protect header when deleting site Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 28/34] dyndbg: unionize _ddebug*_headers with struct _ddebug* Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 29/34] dyndbg: RFC drop _ddebug.site pointer Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 30/34] dyndbg: split/copy ._index into 2 new fields: ._back, ._map Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 31/34] dyndbg: detect repeated site recs in add_module Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 32/34] dyndbg: pack module pr_debug sites Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 33/34] dyndbg: pack pr-debug site-recs in builtin modules Jim Cromie
2021-05-29 20:00 ` [RFC PATCH v6 34/34] dyndbg: prototype print-once and print-ratelimited RFC Jim Cromie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210529200029.205306-21-jim.cromie@gmail.com \
--to=jim.cromie@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox