'-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
From: jim.cromie@gmail.com
Date: 2021-01-28 19:12:53
6 messages, 2 authors, 2021-01-29 · open the first message on its own page
From: jim.cromie@gmail.com
Date: 2021-01-28 19:12:53
hi folks, In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotes
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib@@ -119,7 +119,7 @@ target-stem = $(basename $(patsubst $(obj)/%,%,$@)) # end up in (or would, if it gets compiled in) name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1))) basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) -modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) +modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) -DKBUILD_MODSYM=$(modname)
Im suspicious however, KBUILD_MODNAME has the quotes for a reason; probably robustness at some level. Afterall, __stringify() could add the quotes for cases where it was needed. If there was an __unstringify_token( ) I could remove this Makefile hack, is such a construct possible ?
From: Valdis Klētnieks <hidden>
Date: 2021-01-28 23:57:34
On Thu, 28 Jan 2021 12:11:54 -0700, jim.cromie@gmail.com said:
In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotes
OK, I'll bite. When and how is this useful?
KBUILD_MODNAME has the quotes for a reason;
Hint: do a "git grep KBUILD_MODNAME", look at how it's used, and think about how invasive a patch to change it would be... (And pay heed to the comment in arch/sparc/include/asm/vio.h - it means that there's second-order effects to deal with as well...)
Afterall, __stringify() could add the quotes for cases where it was needed.Afterall, __stringify() could add the quotes for cases where it was needed.
How would it know?
From: jim.cromie@gmail.com
Date: 2021-01-29 00:16:47
On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks [off-list ref] wrote:
On Thu, 28 Jan 2021 12:11:54 -0700, jim.cromie@gmail.com said:quoted
In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotesOK, I'll bite. When and how is this useful?
heres my use
#define DEFINE_DYNAMIC_DEBUG_TABLE_(_sym_,_mod_) \
weak struct _ddebug \
__used __aligned(8) \
__section(".gnu.linkonce." _mod_ ".dyndbg") \
_sym_##_dyndbg_base = { \
.site = &_sym_##_dyndbg_site, \
.format = _mod_, \
.lineno = 0 \
}
#pragma message "OK<" KBUILD_MODNAME ">[" __stringify(KBUILD_MODSYM) "]
adding DYNDBG_TABLE"
#define DEFINE_DYNAMIC_DEBUG_TABLE() \
DEFINE_DYNAMIC_DEBUG_TABLE_(KBUILD_MODSYM, KBUILD_MODNAME);
that pragma does:
from /home/jimc/projects/lx/wk-next/init/version.c:14:
/home/jimc/projects/lx/wk-next/include/linux/dynamic_debug.h:172:9: note:
‘#pragma message: OK<version>[version] adding DYNDBG_TABLE’
172 | #pragma message "OK<" KBUILD_MODNAME ">["
__stringify(KBUILD_MODSYM) "] adding DYNDBG_TABLE"
| ^~~~~~~
CC init/do_mounts.o
IOW the _sym_ works better for ## token-joining
KBUILD_MODNAME has the quotes for a reason; Hint: do a "git grep KBUILD_MODNAME", look at how it's used, and think about how invasive a patch to change it would be... (And pay heed to the comment in arch/sparc/include/asm/vio.h - it means that there's second-order effects to deal with as well...)
I have no intention of changing KBUILD_MODNAME. I created a near-synonym to avoid exactly that.
quoted
Afterall, __stringify() could add the quotes for cases where it wasneeded.Afterall, __stringify() could add the quotes for cases where it was needed. How would it know?
It would not. you would add it to create the quoted version, as I used in the pragma. obviously theres no need, since KBUILD_MODNAME already exists. So question reduces to: is there anything brittle with the Makefile -DKBUILD_MODSYM=$modname addition ?
From: Valdis Klētnieks <hidden>
Date: 2021-01-29 02:05:04
On Thu, 28 Jan 2021 17:16:01 -0700, jim.cromie@gmail.com said:
from /home/jimc/projects/lx/wk-next/init/version.c:14:
/home/jimc/projects/lx/wk-next/include/linux/dynamic_debug.h:172:9: note:
���#pragma message: OK<version>[version] adding DYNDBG_TABLE���
172 | #pragma message "OK<" KBUILD_MODNAME ">["
__stringify(KBUILD_MODSYM) "] adding DYNDBG_TABLE"
| ^~~~~~~
CC init/do_mounts.o
IOW the _sym_ works better for ## token-joiningI meant "step back a bit and explain why you had a need for that #pragma"....
From: jim.cromie@gmail.com
Date: 2021-01-29 08:34:28
On Thu, Jan 28, 2021 at 5:16 PM [off-list ref] wrote:
On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks [off-list ref] wrote:quoted
On Thu, 28 Jan 2021 12:11:54 -0700, jim.cromie@gmail.com said:quoted
In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotesOK, I'll bite. When and how is this useful?
Let me add more context here. 1st, the long saga. v1 - here, back in august last year. https://lore.kernel.org/kernelnewbies/20200805183023.586590-1-jim.cromie@gmail.com/ not really pertinent here. gregkh pretty much said send it to lkml v2 - RFC to LKML https://lore.kernel.org/lkml/20201225201944.3701590-1-jim.cromie@gmail.com/ this didnt get much attention, no answers to my questions the 0000 is still completely accurate, I cannot improve upon it, though many questions in the commit messages Ive answered myself. (or at least made some choices ;) v3 - sits in github now almost identical 1-16/19 with v2 https://github.com/jimc/linux.git dyndbg-next I was hoping to pull off a context-free question, focusing on just the Makefile.lib patch's suitability. I could send the whole series here, or to LKML, or both. I can hope a quick perusal will get you to the interesting parts
heres my use
Im looking to define a module-unique header record, and to create storage for it in a separate section. Then append that section to the module's __dyndbg section. The pragma is leftover scaffolding from trying to figure out that I needed the _sym_ version also, without the quotes. I un-commented for demo only. #define DEFINE_DYNAMIC_DEBUG_TABLE_(_sym_,_mod_) \
weak struct _ddebug \
__used __aligned(8) \
__section(".gnu.linkonce." _mod_ ".dyndbg") \
_sym_##_dyndbg_base = { \
.site = &_sym_##_dyndbg_site, \
.format = _mod_, \
.lineno = 0 \
}
#define DEFINE_DYNAMIC_DEBUG_TABLE() \
DEFINE_DYNAMIC_DEBUG_TABLE_(KBUILD_MODSYM, KBUILD_MODNAME);
I cannot make the _mod_ ## work at the same time as allowing "foo" _mod_ "buzz" catenation, therefore the new _sym_ This DEFINE is "called" from the bottom of include/linux/dynamic_debug.h the combo of weak and ".gnu.linkonce." appear to resolve all all the redundant definitions created by each C files' inclusion of the header. Inspiration came from .gnu.linkonce.this_module
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -329,10 +329,10 @@
#define DYNAMIC_DEBUG_DATA() \ . = ALIGN(8); \ __start___dyndbg_sites = .; \ - KEEP(*(__dyndbg_sites __dyndbg_sites.header)) \ + KEEP(*(__dyndbg_sites .gnu.linkonce.*.dyndbg_site)) \ __stop___dyndbg_sites = .; \ __start___dyndbg = .; \ - KEEP(*(__dyndbg __dyndbg.header)) \ + KEEP(*(__dyndbg .gnu.linkonce.*.dyndbg)) \ __stop___dyndbg = .; #else #define DYNAMIC_DEBUG_DATA() that puts the header record into the output section, right after the module's set of ddebug's (pr_debug callsite descriptors) By getting the header into a fixed position relative to a callsite, its possible to go from callsite-descriptor to the header (after .module_index is initialized with the offset, determined at _init), then use a single per-module pointer to the separate vector of "decorator" data. Once the 2 vectors of __dyndbg and __dyndbg_site records are indexed by N, I can drop the .site pointer from 1 to other, and shrink the footprint back to ~parity (with + 1 record / module overhead) worst case. with 2 vectors fully decoupled (pointer-wise),
From: jim.cromie@gmail.com
Date: 2021-01-29 09:08:06
... and somethings not right. debugger KBUILD_SYM shows it:
these records are same as those shown in early boot output pasted previously
these records look right
(gdb) p *__start___dyndbg_sites@10
$2 = {{modname = 0xffffffff825a8ab9 "head64",
filename = 0xffffffff825a8ac0 "include/linux/dynamic_debug.h",
function = 0xffffffff825a8ab9 "head64"}, {modname = 0xffffffff825a8ade
"ebda",
filename = 0xffffffff825a8ac0 "include/linux/dynamic_debug.h", function
= 0xffffffff825a8ade "ebda"}, {
modname = 0xffffffff825a8ae3 "platform_quirks",
filename = 0xffffffff825a8ac0 "include/linux/dynamic_debug.h",
function = 0xffffffff825a8ae3 "platform_quirks"}, {modname =
0xffffffff825cac42 "main",
filename = 0xffffffff825a8afe "init/main.c",
function = 0xffffffff822000e0 <__func__.2> "run_init_process"},
{modname = 0xffffffff825cac42 "main",
filename = 0xffffffff825a8afe "init/main.c",
function = 0xffffffff822000e0 <__func__.2> "run_init_process"},
{modname = 0xffffffff825cac42 "main",
filename = 0xffffffff825a8afe "init/main.c",
function = 0xffffffff822000e0 <__func__.2> "run_init_process"},
{modname = 0xffffffff825cac42 "main",
filename = 0xffffffff825a8afe "init/main.c",
function = 0xffffffff822000e0 <__func__.2> "run_init_process"},
{modname = 0xffffffff825cac42 "main",
filename = 0xffffffff825a8afe "init/main.c",
function = 0xffffffff822000a0 <__func__.0> "initcall_blacklisted"}, {
modname = 0xffffffff825cac42 "main", filename = 0xffffffff825a8afe
"init/main.c",
function = 0xffffffff822000c0 <__func__.1> "initcall_blacklist"}, {
modname = 0xffffffff825cac42 "main", filename = 0xffffffff825a8ac0
"include/linux/dynamic_debug.h",
function = 0xffffffff825cac42 "main"}}
Theres evidently something wrong with my KBUILD_MODSYM _dyndbg_site here,
the site pointers in all the headers appear the same,
but maybe its just an effect of initialization,