* '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? @ 2021-01-28 19:11 jim.cromie 2021-01-28 23:57 ` Valdis Klētnieks 0 siblings, 1 reply; 6+ messages in thread From: jim.cromie @ 2021-01-28 19:11 UTC (permalink / raw) To: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 852 bytes --] 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 ? [-- Attachment #1.2: Type: text/html, Size: 1070 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? 2021-01-28 19:11 '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? jim.cromie @ 2021-01-28 23:57 ` Valdis Klētnieks 2021-01-29 0:16 ` jim.cromie 0 siblings, 1 reply; 6+ messages in thread From: Valdis Klētnieks @ 2021-01-28 23:57 UTC (permalink / raw) To: jim.cromie; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 686 bytes --] 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? [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? 2021-01-28 23:57 ` Valdis Klētnieks @ 2021-01-29 0:16 ` jim.cromie 2021-01-29 2:04 ` Valdis Klētnieks 2021-01-29 8:32 ` jim.cromie 0 siblings, 2 replies; 6+ messages in thread From: jim.cromie @ 2021-01-29 0:16 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 2111 bytes --] On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: > 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? > > 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. > > 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? > 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 ? [-- Attachment #1.2: Type: text/html, Size: 3335 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? 2021-01-29 0:16 ` jim.cromie @ 2021-01-29 2:04 ` Valdis Klētnieks 2021-01-29 8:32 ` jim.cromie 1 sibling, 0 replies; 6+ messages in thread From: Valdis Klētnieks @ 2021-01-29 2:04 UTC (permalink / raw) To: jim.cromie; +Cc: kernelnewbies [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset=us-ascii, Size: 571 bytes --] 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-joining I meant "step back a bit and explain why you had a need for that #pragma".... [-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? 2021-01-29 0:16 ` jim.cromie 2021-01-29 2:04 ` Valdis Klētnieks @ 2021-01-29 8:32 ` jim.cromie 2021-01-29 9:07 ` jim.cromie 1 sibling, 1 reply; 6+ messages in thread From: jim.cromie @ 2021-01-29 8:32 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 4906 bytes --] On Thu, Jan 28, 2021 at 5:16 PM <jim.cromie@gmail.com> wrote: > > > On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> > wrote: > >> 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? >> >> > 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), the decorator records can be stuffed into compressed block storage, zram, etc, then recovered when a callsite is enabled, and saved into a hashtable, indexed by modname+module-index. global/module hash per experiment. Anyway, I appear to have gotten the header where I want it: [ 0.315519] dyndbg: header: head64 0 [ 0.326702] dyndbg: header: ebda 0 [ 0.342521] dyndbg: header: platform_quirks 0 [ 0.373523] dyndbg: site.4: main run_init_process [ 0.406518] dyndbg: site.5: main run_init_process [ 0.437521] dyndbg: site.6: main run_init_process [ 0.468521] dyndbg: site.7: main run_init_process [ 0.500528] dyndbg: site.8: main initcall_blacklisted [ 0.531519] dyndbg: site.9: main initcall_blacklist [ 0.555520] dyndbg: header: main 0 I have extra headers right now, head64 ebda platform_quirks above, for modules that have no pr-debug callsites. Thats a problem for later, though I posted here about conditional linkage earlier. Im afraid it needs an ld linker language enhancement: KEEP( IF *(__dyndbg) THEN (.gnu.linkonce.dyndbg) ) but Ive yet to try a simpler boolean algrebra KEEP( *(__dyndbg && .gnu.linkonce.dyndbg)) if by some miracle that works, I'll report that shortly. > [-- Attachment #1.2: Type: text/html, Size: 8309 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? 2021-01-29 8:32 ` jim.cromie @ 2021-01-29 9:07 ` jim.cromie 0 siblings, 0 replies; 6+ messages in thread From: jim.cromie @ 2021-01-29 9:07 UTC (permalink / raw) To: Valdis Klētnieks; +Cc: kernelnewbies [-- Attachment #1.1: Type: text/plain, Size: 5141 bytes --] ... 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, which I expect to reshape with a union - struct to use the space efficiently (gdb) p *__start___dyndbg@10 $3 = {{site = 0xffffffff82b252e8 <KBUILD_MODSYM_dyndbg_site>, format = 0xffffffff825a8ab9 "head64", lineno = 0, flags = 0, module_index = 0, key = {dd_key_true = {key = {enabled = {counter = 0}, { type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}, dd_key_false = {key = {enabled = {counter = 0}, {type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}}}, {site = 0xffffffff82b252e8 <KBUILD_MODSYM_dyndbg_site>, format = 0xffffffff825a8ade "ebda", lineno = 0, flags = 0, module_index = 0, key = {dd_key_true = { key = {enabled = {counter = 0}, {type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}, dd_key_false = {key = {enabled = {counter = 0}, {type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}}}, { site = 0xffffffff82b252e8 <KBUILD_MODSYM_dyndbg_site>, format = 0xffffffff825a8ae3 "platform_quirks", lineno = 0, flags = 0, module_index = 0, key = {dd_key_true = {key = {enabled = {counter = 0}, { type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}, dd_key_false = {key = {enabled = {counter = 0}, {type = 0, entries = 0x0 <fixed_percpu_data>, next = 0x0 <fixed_percpu_data>}}}}}, { site = 0xffffffff82b25330 <__UNIQUE_ID_ddebug468_site.13>, format = 0xffffffff82653f07 " %s\n", lineno = 1349, flags = 1, module_index = 0, key = {dd_key_true = {key = {enabled = {counter = 1}, { type = 18446744071602861249, entries = 0xffffffff826e74c1, next = 0xffffffff826e74c1}}}, dd_key_false = {key = {enabled = {counter = 1}, {type = 18446744071602861249, entries = 0xffffffff826e74c1, next = 0xffffffff826e74c1}}}}}, { site = 0xffffffff82b25348 <__UNIQUE_ID_ddebug467_site.15>, format = 0xffffffff825a8b59 " with environment:\n", lineno = 1347, flags = 1, module_index = 0, key = {dd_key_true = {key = {enabled = {counter = 1}, {type = 18446744071602861265, entries = 0xffffffff826e74d1, next = 0xffffffff826e74d1}}}, dd_key_false = {key = {enabled = { counter = 1}, {type = 18446744071602861265, entries = 0xffffffff826e74d1, next = 0xffffffff826e74d1}}}}}, {site = 0xffffffff82b25360 <__UNIQUE_ID_ddebug466_site.17>, format = 0xffffffff82653f07 " %s\n", lineno = 1346, flags = 1, module_index = 0, key = { dd_key_true = {key = {enabled = {counter = 1}, {type = 18446744071602861281, entries = 0xffffffff826e74e1, next = 0xffffffff826e74e1}}}, dd_key_false = {key = {enabled = { counter = 1}, {type = 18446744071602861281, entries = 0xffffffff826e74e1, next = 0xffffffff826e74e1}}}}}, {site = 0xffffffff82b25378 <__UNIQUE_ID_ddebug465_site.19>, format = 0xffffffff825a8b46 " with arguments:\n", lineno = 1344, flags = 1, module_index = 0, key = { dd_key_true = {key = {enabled = {counter = 1}, {type = 18446744071602861297, at any rate, I'll probly work this a bit, see if I can resolve a few problems [-- Attachment #1.2: Type: text/html, Size: 6320 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-01-29 9:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-28 19:11 '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ? jim.cromie 2021-01-28 23:57 ` Valdis Klētnieks 2021-01-29 0:16 ` jim.cromie 2021-01-29 2:04 ` Valdis Klētnieks 2021-01-29 8:32 ` jim.cromie 2021-01-29 9:07 ` jim.cromie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).