On Wed, 2022-01-05 at 12:30 -0500, Bruce Ashfield wrote:
> On Wed, Jan 5, 2022 at 12:07 PM Richard Purdie
> <[email protected]> wrote:
> > 
> > On Tue, 2022-01-04 at 14:07 -0800, Saul Wold wrote:
> > > 
> > > On 12/22/21 01:09, Richard Purdie wrote:
> > > > On Tue, 2021-12-21 at 11:08 -0800, Saul Wold wrote:
> > > > > Stop ignoring or skipping the kernel and kernel modules code in the
> > > > > split debug and striping functions, this will allow create_spdx to
> > > > > process the kernel and modules.
> > > > > 
> > > > > Signed-off-by: Saul Wold <[email protected]>
> > > > > ---
> > > > >   meta/classes/package.bbclass | 8 ++------
> > > > >   1 file changed, 2 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/meta/classes/package.bbclass 
> > > > > b/meta/classes/package.bbclass
> > > > > index 84eafbd529..4b7fe4f1e1 100644
> > > > > --- a/meta/classes/package.bbclass
> > > > > +++ b/meta/classes/package.bbclass
> > > > > @@ -390,10 +390,6 @@ def splitdebuginfo(file, dvar, debugdir, 
> > > > > debuglibdir, debugappend, debugsrcdir,
> > > > >       dvar = d.getVar('PKGD')
> > > > >       objcopy = d.getVar("OBJCOPY")
> > > > > 
> > > > > -    # We ignore kernel modules, we don't generate debug info files.
> > > > > -    if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
> > > > > -        return (file, sources)
> > > > > -
> > > > >       newmode = None
> > > > >       if not os.access(file, os.W_OK) or os.access(file, os.R_OK):
> > > > >           origmode = os.stat(file)[stat.ST_MODE]
> > > > > @@ -1147,7 +1143,7 @@ python split_and_strip_files () {
> > > > > 
> > > > >                   if file.endswith(".ko") and 
> > > > > file.find("/lib/modules/") != -1:
> > > > >                       kernmods.append(file)
> > > > > -                    continue
> > > > > +
> > > > >                   if oe.package.is_static_lib(file):
> > > > >                       staticlibs.append(file)
> > > > >                       continue
> > > > > @@ -1165,7 +1161,7 @@ python split_and_strip_files () {
> > > > >                       continue
> > > > >                   # Check its an executable
> > > > >                   if (s[stat.ST_MODE] & stat.S_IXUSR) or 
> > > > > (s[stat.ST_MODE] & stat.S_IXGRP) or (s[stat.ST_MODE] & stat.S_IXOTH) \
> > > > > -                        or ((file.startswith(libdir) or 
> > > > > file.startswith(baselibdir)) and (".so" in f or ".node" in f)):
> > > > > +                        or ((file.startswith(libdir) or 
> > > > > file.startswith(baselibdir)) and (".so" in f or ".node" in f)) or 
> > > > > (f.startswith('vmlinux') or ".ko" in f):
> > > > > 
> > > > >                       if cpath.islink(file):
> > > > >                           checkelflinks[file] = ltarget
> > > > 
> > > > edgerouter:
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/4513
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/2507/steps/11/logs/stdio
> > > > 
> > > So I have been digging into this and it seems that an option was added a
> > > decade ago or so to strip the kernel/vmlinux when it's too big, this was
> > > done for at least the routerstationpro according to bug #3515 [0], and
> > > persists with the edgerouter, although I am not sure if it would still
> > > actually be required as the edgerouter also uses the
> > > KERNEL_ALT_IMAGETYPE to create a smaller binary kernel image.
> > > 
> > > The change I proposed causes the all kernels to be stripped all the time
> > > as part of the split_and_strip_files(). As I see it there few different
> > > options:
> > > 
> > > 1) Set KERNEL_IMAGE_EXTRA_STRIP_SECTIONS = "" in create_spdx.bbclass
> > >    - This solves the problem with create_spdx.bbclass is in use, but not
> > > the general case
> > 
> > I don't think I like this as it is a side effect that isn't obvious or 
> > expected.
> > 
> > > 
> > > 2) Remove the KERNEL_IMAGE_EXTRA_STRIP_SECTIONS from edgerouter.conf
> > >    - Will solve the edgerouter case but may not solve other usages
> > > unknown to me.
> > >    - Does anyone know of other machines/layers usage of this variable?
> > > 
> > > 3) deprecate the kernel.bbclass:do_strip function in favor of using the
> > > split_and_strip_files() of package.bbclass
> > 
> > I know Bruce has said he doesn't like this, however stepping back, these 
> > issues
> > were from a time our stripping code was young and evolving. If we can
> > standardise and have it all work together well in one set of functions, I 
> > think
> > that is worth looking at. I'd prefer the kernel wasn't a special case if it 
> > no
> > longer needs to be.
> > 
> > That said, I don't remember the details of why we did this.
> 
> There's a middle ground of debug being possible, and some sections
> removed to keep the footprint a bit lower. There were also some
> unwinders, etc, that didn't work when everything was stripped and
> split into debug. The stripping was too aggressive, and removed some
> sections that were required.
> 
> While I can't exactly point to the use cases for it now, with the 5K
> options in the kernel, they haven't all been removed, and I'd be very
> hesitant to remove the capability completely.

What may help would be to move the kernel stripping code from kernel.bbclass to
live along with the package stripping code, which would then at least solve some
of the QA warning issues and the two code blocks not fighting with each other.
it would also allow the debug symbols to move to the linked debug files where
appropriate more easily.

I think one of the challenges in doing that is the do_deploy of the kernel image
though which may not then have the right stripping :(.

We may be able to call the strip function from do_deploy though?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160213): 
https://lists.openembedded.org/g/openembedded-core/message/160213
Mute This Topic: https://lists.openembedded.org/mt/87884056/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to