On Sat, Mar 15, 2025 at 04:56:35AM +0900, Masahiro Yamada wrote:
> Sorry for the long delay.
No worries and thanks for the review!
> On Tue, Feb 11, 2025 at 10:12 AM Uday Shankar <ushankar@xxxxxxxxxxxxxxx> wrote:
> > Note that this feature is incompatible with CONFIG_MODULE_COMPRESS -
> > if it is turned on, the module .ko files are compressed before
> > find-debuginfo.sh sees them, and it will not be able to extract
> > debuginfo from them. There are two potential paths forward here:
> > - teach find-debuginfo.sh to extract debuginfo from compressed kernel
> > modules
> > - teach the kernel build process to produce split debuginfo and then
> > package that directly, bypassing find-debuginfo.sh
>
>
> 'make bindeb-pkg' (Debian package) is able to build the debug package with
> CONFIG_MODULE_COMPRESS enabled.
> (see scripts/package/builddeb if you are interested)
> I have not checked if this works for 'make binrpm-pkg' or not.
> If this is a tricky case, I am OK with giving up CONFIG_MODULE_COMPRESS.
scripts/package/builddeb is able to do this because it is more hands-on
with the debuginfo generation - it invokes objcopy --only-keep-debug
directly. Meanwhile for rpm-pkg we are relying on find-debuginfo.sh for
the debuginfo generation - we just set things up appropriately (meaning
that we mark everything to be stripped as executable), and
find-debuginfo.sh does the rest. This means we can get debuginfo without
working as hard, but our flexibility is limited - without nasty hacks,
we cannot really handle compressed modules unless/until
find-debuginfo.sh is patched to handle them.
I could try revising this to remove the dependency on find-debuginfo.sh
and strip the debuginfo ourselves. Then we could handle compressed
modules the same way that deb-pkg does.
> > +# make modules executable so that find-debuginfo.sh strips them
> > +find %{buildroot}/lib/modules/%{KERNELRELEASE} -name "*.ko" -type f \
> > + | xargs --no-run-if-empty chmod u+x
>
> This seems necessary and correct.
>
> One side-effect I noticed is that *.ko under /lib/modules/$(uname -r)/
> now have +x permissions. (Previously, they were non-executables).
>
> I checked Fedora. Modules under /lib/modules/$(uname -r)/
> do not have +x permissions.
>
> Do you know how Fedora's kernel.spec handles this?
I'm looking at
https://koji.fedoraproject.org/koji/buildinfo?buildID=2661097
The spec file for that package actually does something similar to what
we're doing above; it has this excerpt
# mark modules executable so that strip-to-file can strip them
xargs --no-run-if-empty chmod u+x < modnames
But later on it compresses the modules, using some RPM macro magic to
ensure that happens _after_ find-debuginfo.sh has seen and stripped the
executable modules. The compression eats the executable bit.
> > +
> > +%if %{with_debuginfo}
> > +mkdir -p %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}
> > +cp vmlinux %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}
> > +%endif
> > +
> > %clean
> > rm -rf %{buildroot}
> > +rm -f debugfiles.list debuglinks.list debugsourcefiles.list debugsources.list \
> > + elfbins.list
> >
> > %post
> > if [ -x /usr/bin/kernel-install ]; then
> > diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> > index 4dc1466dfc815c110eb7206f83dd874b17f5170f..4c96bdca381a2fb4cc57415ca914d14e37e16caa 100755
> > --- a/scripts/package/mkspec
> > +++ b/scripts/package/mkspec
> > @@ -23,6 +23,9 @@ else
> > echo '%define with_devel 0'
> > fi
> >
> > +WITH_DEBUGINFO=$(grep -c CONFIG_DEBUG_INFO=y include/config/auto.conf)
> > +echo "%define with_debuginfo ${WITH_DEBUGINFO}"
> > +
>
> How about this code?
>
> if grep -q CONFIG_DEBUG_INFO=y include/config/auto.conf; then
> echo '%define with_debuginfo %{?_without_debuginfo: 0}
> %{?!_without_debuginfo: 1}'
> else
> echo '%define with_debuginfo 0'
> fi
>
> This allows users to skip the debuginfo package
> and aligns with the existing code a few lines above.
>
> Also, it is compatible with Fedora's kernel.spec.
> https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_236
>
>
> If you do not support CONFIG_MODULE_COMPRESS,
> you can check it here.
Yes, both suggestions make sense, thanks. Will implement these in v2.
