[pacman-dev] [PATCH v3] makepkg: implement support for stripping kernel modules

[Steven Noonan]

On Sun, Feb 9, 2014 at 8:32 PM, Allan McRae <allan at archlinux.org> wrote:
> On 10/02/14 09:26, Steven Noonan wrote:
>> I noticed when I built a kernel package with options 'strip' and 'debug' that
>> the debug package was missing the debug information for the kernel modules.
>> This patch adds kernel modules to the targets for 'strip' and is compatible
>> with the split-out debug information packages.
>>
>> v2: Correct logic error -- did a 'continue' after the 2nd-level case statement
>>     instead of in the default case.
>> v3: Oops, forgot to terminate outer case. Ran this version through the test
>>     suite and all tests passed.
>>
>
> For future reference, put comments like these ....
>
>> Signed-off-by: Steven Noonan <steven at uplinklabs.net>
>> ---
>
> ... under this line.  That way they are ignored when committing the patch.

I'll bear that in mind, thanks for pointing it out.

>
>>  scripts/makepkg.sh.in | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
>> index 940e947..027fcc3 100644
>> --- a/scripts/makepkg.sh.in
>> +++ b/scripts/makepkg.sh.in
>> @@ -1659,6 +1659,13 @@ tidy_install() {
>>                                       strip_flags="$STRIP_SHARED";;
>>                               *application/x-archive*)    # Libraries (.a)
>>                                       strip_flags="$STRIP_STATIC";;
>> +                             *application/x-object*)
>> +                                     case "$binary" in
>> +                                             *.ko)                   # Kernel module
>> +                                                     strip_flags="$STRIP_SHARED";;
>> +                                             *)
>> +                                                     continue;;
>> +                                     esac;;
>
> This looks fine to me.
>
> I notice the Arch Linux kernel package uses options=('!strip').  I am
> lead to believe that stripping vmlinux lead to issues with building
> modules.  Also the Arch PKGBUILD compresses the modules before it gets
> to stripping the files.

I maintain the Arch Linux EC2 kernel, and I'm doing adventurous things
with the packaging to make debugging a bit easier. I am looking at
enabling CONFIG_DEBUG_INFO and adding -debug packages. That will
indeed require removing the compression stage for the modules. In my
experience this has had no negative impact. In fact, tools like 'perf'
look for separate debug symbols.

As for module builds, you're correct:

  MODPOST 1 modules
FATAL: vmlinux has no symtab?
/usr/src/linux-3.13.2-1-ec2/scripts/Makefile.modpost:90: recipe for
target '__modpost' failed
make[1]: *** [__modpost] Error 1

The build still fails even if the -debug packages are installed alongside.


I'd argue however that this doesn't impact this patch directly --
splitting debug symbols from the kernel modules is OK, but stripping
vmlinux is not. This could be worked around by:

1. Moving vmlinux into linux-headers. vmlinux is kind of an oddball
(only item in /usr/src/linux for the main package) -- maybe I'm
missing context as to why it's in the 'linux' package? it seems like
you'd need the -headers package for a module build anyway, so it can't
be there just for module builds.
2. Change linux-headers to use options=('!strip'). This also avoids
the strange side effect of having a -debug for linux *and*
linux-headers.

I just tested the above and successfully built a module. So I guess
the question is if vmlinux really needs to be in the primary package
(and I'd be curious to know why, if so).


> So, I guess my question is...  Well, I'm not sure!  I think I just need
> a more complete picture to asses this.  Is my interpretation of the
> issue with stripping vmlinux right? Does having separate debug symbols
> for vmlinux still allow modules be built? How do compressed modules and
> separate debug symbols interact?

Well, as mentioned above, 'perf' behavior is now more reasonable (e.g.
'Test object code reading' in 'perf test' passes now). I'm also
getting better results out of sampling with 'perf'. This behavioral
improvement sort of makes sense since the primary developers of it are
RedHat folks and splitting out debuginfo is how RedHat packages their
kernels.