ppc64le bzImage and Build_id elf note

[Donald Zickus]

On Wed, Jun 8, 2022 at 7:52 AM Michael Ellerman <mpe at ellerman.id.au> wrote:

> Donald Zickus <dzickus at redhat.com> writes:
> > Hi Michael,
> >
> > I am working on two packaging issues with Fedora and CKI that I am hoping
> > you can give me some guidance on.
> >
> > 1 - Fedora has always packaged an eu-strip'd vmlinux file for powerpc.
> The
> > other arches we support used native compressed images.  I was looking
> into
> > using powerpc's zImage (pseries) binary to remove the powerpc workarounds
> > in our rpm spec file.
>
> What's the motivation for using the zImage?
>
> My naive hope was that as more advanced boot loaders become the norm we
> could eventually get rid of the zImage.
>
> It's generally a pain to work with, and a bit crufty, it also doesn't
> get as much testing as booting the vmlinux, so I'd be a little wary of
> switching to it.
>

My motivation really is to remove some of manual stripping out of our
specfile and use something more community builtin and address my second
issue.

If zImage isn't the right path to pursue, that is fine by me.  Perhaps I
just want vmlinux.stripped.


> There's also multiple zImages (and others), although admittedly for the
> platforms that Fedora supports the zImage.pseries should work (I think).
>
> > However, the rpmbuild fails because it can't find a build-id with
> > eu-readelf -n zImage.  Sure enough the build-id is found in vmlinux and
> > vmlinux.stripped but disappears with vmlinux.stripped.gz.
>
> Looks like other arches use objcopy rather than strip, maybe that's it?
>
> > I had hoped
> > arch/powerpc/boot/addnote would stick it back in but it doesn't (I am
> > ignorant of how addnote works).
>
> addnote adds some notes that firmware needs to read, it doesn't do
> anything else, though maybe it could.
>
> > eu-readelf -n  data
> > vmlinux:
> >
> > Displaying notes found in: .notes
> >   Owner                Data size        Description
> >   GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID
> > bitstring)
> >     Build ID: b4c026d72ead7b4316a221cddb7f2b10d75fb313
> >   Linux                0x00000004       func
> >    description data: 00 00 00 00
> >   Linux                0x00000001       OPEN
> >    description data: 00
> >   PowerPC              0x00000004       NT_VERSION (version)
> >    description data: 01 00 00 00
> >
> > zImage:
> >
> > Displaying notes found at file offset 0x00000158 with length 0x0000002c:
> >   Owner                Data size        Description
> >   PowerPC              0x00000018       Unknown note type: (0x00001275)
> >    description data: ff ff ff ff 02 00 00 00 ff ff ff ff ff ff ff ff ff
> ff
> > ff ff 00 00 40 00
> >
> > Displaying notes found at file offset 0x00000184 with length 0x00000044:
> >   Owner                Data size        Description
> >   IBM,RPA-Client-[...] 0x00000020       Unknown note type: (0x12759999)
> >    description data: 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 28 00
> 00
> > 00 01 ff ff ff ff 00 00 00 00 00 00 00 01
> >
> > Is this something that can be addressed?  Or should I/we expect the
> > build-id to never make it into the zImage and just continue with our
> > current vmlinux process?
>
> Maybe :)
>
> Is it correct for the build-id to be copied into the zImage anyway? It's
> a different binary so shouldn't it have a different build-id?
>
> If you have a zImage and a vmlinux with the same build-id isn't that
> going to confuse debugging tools?
>

My understanding is the debug tools use vmlinux anyway (at least for
Fedora) which is stored in our -debuginfo package.  While the booted image
(compressed) is stored in the traditional kernel rpm.  My understanding is
the build is the same whether compressed or not so having a similar
build-id made sense.  But I am a little ignorant here.



> > 2 - CKI builds kernels using 'make targz-pkg'.  The arches we support
> > (x86_64, s390, aarch64) provide compressed binaries to package using
> > KBUILD_IMAGE or a specific entry in scripts/package/buildtar.  As a
> result,
> > because powerpc doesn't have a KBUILD_IMAGE variable defined, the script
> > builds vmlinx and cp's that to vmlinux-kbuild.  The problem with powerpc
> is
> > that vmlinux for us is huge ( >256MB) and cp'ing that to vmlinux-kbuild
> > occupies > 512MB of /boot and our distro runs out of disk space on that
> > partition.
>
> Is that just because it has debug info built in? I thought the distro
> solution for that was doing split debug info?
>

Yes, our rpm specfile stores vmlinux in -debuginfo and strips vmlinux to
store in the normal kernel rpm.

But our kernel CI service, CKI uses the upstream's 'make targz-pkg' for
easier consumption by the upstream community that may not use rpms.  That
Makefile target doesn't have any stripping.  I was hoping to add that.


>
> > I was hoping to add a patch to arch/powerpc/Makefile that defines
> > KBUILD_IMAGE:=$(boot)/zImage (mimicing arch/s390), which I believe would
> > solve our problem.  However, that circles back to our first problem
> above.
> >
> > Thoughts?  Help?
>

> Happy to try and help, though see my concerns at the top about using
> zImage.
>

If zImage isn't the right approach, would you be open to adding a variable
in arch/powerpc/Makefile

KBUILD_IMAGE:= $(obj)/vmlinux.strip

though I think that file is created and removed while building the zImage.


It is a small tweak, but one I was trying to avoid hacking into our source
code.

Cheers,
Don


> cheers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20220613/add21431/attachment-0001.htm>