ppc64le bzImage and Build_id elf note

[Michael Ellerman]

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.

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?

> 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?

> 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.

cheers