* ppc64le bzImage and Build_id elf note
@ 2022-06-03 13:49 Donald Zickus
2022-06-08 11:52 ` Michael Ellerman
0 siblings, 1 reply; 4+ messages in thread
From: Donald Zickus @ 2022-06-03 13:49 UTC (permalink / raw)
To: mpe
Cc: Bruno Goncalves, Justin Forbes, linuxppc-dev, Daniel Horak,
Veronika Kabatova
[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]
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.
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. I had hoped
arch/powerpc/boot/addnote would stick it back in but it doesn't (I am
ignorant of how addnote works).
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?
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.
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?
Cheers,
Don
[-- Attachment #2: Type: text/html, Size: 3309 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: ppc64le bzImage and Build_id elf note 2022-06-03 13:49 ppc64le bzImage and Build_id elf note Donald Zickus @ 2022-06-08 11:52 ` Michael Ellerman 2022-06-08 17:36 ` Segher Boessenkool 2022-06-13 20:34 ` Donald Zickus 0 siblings, 2 replies; 4+ messages in thread From: Michael Ellerman @ 2022-06-08 11:52 UTC (permalink / raw) To: Donald Zickus Cc: Bruno Goncalves, Justin Forbes, linuxppc-dev, Daniel Horak, Veronika Kabatova Donald Zickus <dzickus@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ppc64le bzImage and Build_id elf note 2022-06-08 11:52 ` Michael Ellerman @ 2022-06-08 17:36 ` Segher Boessenkool 2022-06-13 20:34 ` Donald Zickus 1 sibling, 0 replies; 4+ messages in thread From: Segher Boessenkool @ 2022-06-08 17:36 UTC (permalink / raw) To: Michael Ellerman Cc: Donald Zickus, Justin Forbes, Bruno Goncalves, Daniel Horak, Veronika Kabatova, linuxppc-dev On Wed, Jun 08, 2022 at 09:52:25PM +1000, Michael Ellerman wrote: > What's the motivation for using the zImage? You cannot boot a vmlinux from OF directly, with most PowerPC OF implementations. You *can* boot a zImage directly (with some trickery sometimes). That is one reason to use zImage, probably not a very important reason for most people though. Segher ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ppc64le bzImage and Build_id elf note 2022-06-08 11:52 ` Michael Ellerman 2022-06-08 17:36 ` Segher Boessenkool @ 2022-06-13 20:34 ` Donald Zickus 1 sibling, 0 replies; 4+ messages in thread From: Donald Zickus @ 2022-06-13 20:34 UTC (permalink / raw) To: Michael Ellerman Cc: Bruno Goncalves, Justin Forbes, linuxppc-dev, Daniel Horak, Veronika Kabatova [-- Attachment #1: Type: text/plain, Size: 5475 bytes --] On Wed, Jun 8, 2022 at 7:52 AM Michael Ellerman <mpe@ellerman•id.au> wrote: > Donald Zickus <dzickus@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 > > [-- Attachment #2: Type: text/html, Size: 7587 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-14 22:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-06-03 13:49 ppc64le bzImage and Build_id elf note Donald Zickus 2022-06-08 11:52 ` Michael Ellerman 2022-06-08 17:36 ` Segher Boessenkool 2022-06-13 20:34 ` Donald Zickus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox