On 9/21/26 2:48 PM, Lorenzo Stoakes (ARM) wrote: > On Mon, Sep 21, 2026 at 02:36:30PM +0200, Petr Pavlu wrote: >> On 9/21/26 1:57 PM, Lorenzo Stoakes (ARM) wrote: >>> (note there's a v3 see [0]) >>> >>> [0]: >>> https://lore.kernel.org/linux-kbuild/[email protected]/ >> >> Thanks, I missed it. >> >>> On Mon, Sep 21, 2026 at 01:25:09PM +0200, Petr Pavlu wrote: >>>> On 9/14/26 11:22 AM, Lorenzo Stoakes (ARM) wrote: >>>>> The sections were confirmed to be byte-for-byte identical to the C version >>>>> produced - each of .modinfo, .gnu.linkonce.this_module, __ksymtab*, >>>>> __ksymtab_strings, __kcrctab*, __kflagstab*, __versions, >>>>> __version_ext_crcs, __version_ext_names and their relocations - for all >>>>> 8,135 modules of a clang allmodconfig build with CONFIG_COMPILE_TEST off >>>>> and CONFIG_MODVERSIONS, CONFIG_EXTENDED_MODVERSIONS and >>>>> CONFIG_MODULE_SRCVERSION_ALL on, and for a sample built with gcc. >>>> >>>> Lowering the data to assembly loses debug information for __this_module, >>>> specifically that it has type `struct module`. It might be worth >>> >>> No, it keeps it - every module includes linux/module.h, and the extern >>> declaration of __this_module carries the type, so all of the stuff gdb >>> needs (e.g. ptype, p & field access), DWARF etc. is all there in the same >>> way as with .mod.c. >>> >>> Have confirmed locally. >> >> An extern declaration alone shouldn't cause its name and type to be >> included in debug information. They should appear only when the variable >> is referenced by some code. > > Ack yeah sorry my mistake, I had the LLM check that and should have known > better than to trust it without reviewing what it said (as I have done for > the most part for everything in this series). > >> >> Testing with a simple module that previously referenced __this_module >> only in .mod.c and in no other file, such as lib/test_module.c, shows >> that the .ko no longer contains debug information for this variable. >> >> I've verified this behavior with GCC 16 and Clang 19. > > Ack confirmed locally. > > Can put a fix in module-common.c. > > The LLM came up with a reference as an alternative: > > static struct module *const __this_module_dbg __used > __section(".discard.this_module") = &__this_module; > > Would that work? Or should we go with your original suggestion? - > > __weak __section(".discard.this_module") struct module __this_module;
With GCC, the LLM's suggestion produces debug information for both __this_module_dbg and __this_module. However, Clang only generates debug information for __this_module_dbg, so it is not quite what is needed. -- Thanks, Petr
