* '-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).