Re: [PATCH v2 13/21] modpost: emit module descriptors as assembly

[Lorenzo Stoakes (ARM)]

On Mon, Sep 21, 2026 at 03:50:06PM +0200, Petr Pavlu wrote:
> 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/20260917-build-speedup-v3-0-9ecf4163ff36@xxxxxxxxxx/
> >>
> >> 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.

Ack will go with your suggestion then, thanks! Will be applied to v4.

I am aiming for ~midweek for sending that that out to give people a chance to
respond and because it'll be based on other pending commits that need a bit of
time before they're in-tree.

I have added you to the cc-list so you should get mailed when I send it out!

Thanks for the feedback :)

>
> --
> Thanks,
> Petr

--
Cheers, Lorenzo