From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0CD2C43460 for ; Tue, 11 May 2021 18:51:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 80808611AB for ; Tue, 11 May 2021 18:51:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80808611AB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3F0E16B0093; Tue, 11 May 2021 14:51:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32C726B0095; Tue, 11 May 2021 14:51:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 044E96B0096; Tue, 11 May 2021 14:51:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id CA1AE6B0093 for ; Tue, 11 May 2021 14:51:48 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 786818249980 for ; Tue, 11 May 2021 18:51:48 +0000 (UTC) X-FDA: 78129844296.08.34050A0 Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by imf08.hostedemail.com (Postfix) with ESMTP id EE65B80192E7 for ; Tue, 11 May 2021 18:51:20 +0000 (UTC) Received: by mail-il1-f172.google.com with SMTP id h6so18058058ila.7 for ; Tue, 11 May 2021 11:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1zPO68rECc+Worbr8mpoHDMicmfWQWDsecrogWsDsoQ=; b=lUOzvKR7OcFpY3RFzFgr4FfdY+ltDTeD+w+XTPlSXAD60lNeu0OutmmA3OapNwiIOs iOGGjwpez+HzgWZKjsLeHv/b7ne6PJXQGzWgJEryLJMkUuLeRJDhkHtKfnfQN54XHv+t iWg5/I8gU7sXudG/yQXuwEKlLk5+RqDXvgIL23dhr63JSghTd4PPQBtoSPw88Xe0mYb1 mdXZW4KQgIBgzqPRDkt46MQleqFIO14rbyTwJN77jc9KKKIJDnhc4K1S1qgtwqFK5cSI b5GCLFGyh7G5KxULcx9wtTmd/9ugmEXaDIcDl87WA3cq6Si7oKgmknwsAeKY6p7ODVW5 koRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1zPO68rECc+Worbr8mpoHDMicmfWQWDsecrogWsDsoQ=; b=kvQNaAZrpk7duwNN2Hb2Nxr+OJqrJrf9SFo0I+BKPYkd5SR5mbt8EtpBtgWdlf/1qK dseUDrlaJo2RxUbTtu3EUybrfE5nGRoT9kKENKZotAY+aOlyHvLI/41hmlWzwf7o2Cij OKpyHcFX/Jhn4uvZ+SrezeQrbUwZXjDUJarCsWZ+NRJVcbOzGmBaQHq6ZpO74+925uvc lixvfQacObxHs8fsc8xLG0HldQEgIAB2dn1ObEkLfGmqlDVImUSvuqtba3LEC/2FR9oJ CgXvvYjyLtGzs1xQn60OHSkYohEcqAv+VZ1PNgjiYgNbdwzn9VAE90HJFPEhZ7IW0oWu JX6A== X-Gm-Message-State: AOAM532Q38e0u3Pjkriad9uJD8IN0ndaiA9kgEvH0Yz8i1u7rn5TtRA/ NzZ8zIBzDbpYDRlg6Yf2kBo= X-Google-Smtp-Source: ABdhPJzgH2JupKPauvVNrxewRnPOgZT9DsS7spCYIvNf3mENzkbGKi8D+JbpvRz4e1wSrzR8pbrZeQ== X-Received: by 2002:a92:cf05:: with SMTP id c5mr25905167ilo.225.1620759107543; Tue, 11 May 2021 11:51:47 -0700 (PDT) Received: from frodo.mearth (c-24-9-77-57.hsd1.co.comcast.net. [24.9.77.57]) by smtp.googlemail.com with ESMTPSA id t10sm405096ils.36.2021.05.11.11.51.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 11:51:47 -0700 (PDT) From: Jim Cromie To: Arnd Bergmann , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Jim Cromie Subject: [RFC PATCH v5 19/28] dyndbg: RFC handle __dyndbg* sections in module.lds.h Date: Tue, 11 May 2021 12:50:48 -0600 Message-Id: <20210511185057.3815777-20-jim.cromie@gmail.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210511185057.3815777-1-jim.cromie@gmail.com> References: <20210511185057.3815777-1-jim.cromie@gmail.com> MIME-Version: 1.0 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=lUOzvKR7; spf=pass (imf08.hostedemail.com: domain of jimcromie@gmail.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=jimcromie@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EE65B80192E7 X-Stat-Signature: yeq98hn5eqobyibgnsx3ks84ysg3s7i3 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mail-il1-f172.google.com; client-ip=209.85.166.172 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620759080-40465 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 place the header sections in front of their respective __dyndbg* sections, so 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=3D=3Dmodule && !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, 1073= 7418240 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_power= cap.1159 [ 8.104960] dyndbg: 5 5 intel_rapl_common.rapl_package_register_power= cap.1145 [ 8.106246] dyndbg: 6 6 intel_rapl_common.rapl_package_register_power= cap.1114 [ 8.107302] dyndbg: 7 7 intel_rapl_common.rapl_package_register_power= cap.1108 [ 8.108338] dyndbg: 8 8 intel_rapl_common.rapl_update_domain_data.108= 3 [ 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 <=3D 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 --- include/asm-generic/module.lds.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/include/asm-generic/module.lds.h b/include/asm-generic/modul= e.lds.h index f210d5c1b78b..328c48dfc88c 100644 --- a/include/asm-generic/module.lds.h +++ b/include/asm-generic/module.lds.h @@ -4,7 +4,17 @@ =20 /* * can specify arch-specific sections for linking mod= ules. - * Empty for the asm-generic header. + * + * For loadable modules with CONFIG_DYNAMIC_DEBUG, we need to keep the + * 2 __dyndbg* ELF sections, which are loaded by module.c + * + * Pack the 2 __dyndbg* input sections with their respective + * .gnu.linkonce. header records into 2 output sections, with those + * header records in the 0th element. */ +SECTIONS { +__dyndbg_sites : ALIGN(8) { *(.gnu.linkonce.dyndbg_site) *(__dyndbg_site= s) } +__dyndbg : ALIGN(8) { *(.gnu.linkonce.dyndbg) *(__dyndbg) } +} =20 #endif /* __ASM_GENERIC_MODULE_LDS_H */ --=20 2.31.1