On Thu, May 13, 2021 at 3:36 AM Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> couple colleagues asked me about the details of how the debug
> filesystem is created, and since i wasn't entirely clear on the
> mechanics of it myself, i thought i'd dig into it, so a couple
> preliminary questions to make sure i'm on the right track.
>
> trivially, if you want that companion debugfs, you need only:
>
> IMAGE_GEN_DEBUGFS = '1'
>
> at which point what kicks in is the current value of
> IMAGE_FSTYPES_DEBUGFS to determine what forms of the debugfs you want.
> by default, that's conditionally set to "tar.gz" in bitbake.conf so,
> unless you mess with it, the end result is a debugfs tarball under
> deploy/images. so far, so good.
>
> now, if you (for no good reason) also set:
>
> IMAGE_FSTYPES_DEBUGFS = ''
>
> in your local.conf, then even though you *claim* you want the debugfs,
> you're not going to get one since the build process has no idea what
> archive type you want. i believe this is the result of this snippet in
> image.bbclass in the anonymous python routine (line 369):
>
> if d.getVar('IMAGE_GEN_DEBUGFS') == "1":
> debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS').split()
> for t in debugfs_fstypes:
> alltypes.append("debugfs_" + t)
>
> which makes sense. however, even if you don't get the final debugfs
> tarball under deploy, i see that the *contents* of the debugfs are
> still generated under WORKDIR for the image (in my case,
> core-image-minimal), since i see both:
>
> rootfs/
> rootfs-dbg/
>
> and following the trail of bread crumbs to see where that came from, i
> ended up in meta/lib/oe/rootfs.py:
>
> def _setup_dbg_rootfs(self, dirs):
> gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
> if gen_debugfs != '1':
> return
>
> bb.note(" Renaming the original rootfs...")
> try:
> shutil.rmtree(self.image_rootfs + '-orig')
> except:
> pass
> bb.utils.rename(self.image_rootfs, self.image_rootfs + '-orig')
>
> ... and so on and so on ...
>
> which clearly(?) does all that work, even if, in the end, the result
> is not packaged as a tarball, which is part of what muh colleagues
> were asking about -- where can they see *exactly* how that debugfs
> content is collected?
>
> is all this reasonably accurate so far?
Yes, I think so. Creation of the debugfs tar file uses a lot of the
same logic as creation of the rootfs image(s) so is controlled by
similar variables (e.g. IMAGE_FSTYPES_DEBUGFS is the equivalent of
IMAGE_FSTYPES). In theory you could change IMAGE_GEN_DEBUGFS to create
(for example) a squashfs image containing the debug symbols, but since
the debug symbols are going to be used on the host (and not copied
into Flash on the target etc) it doesn't make much sense to do so. In
practice the only reason you might want to change the default value of
IMAGE_GEN_DEBUGFS would be if you prefer .tar.bz2 etc over .tar.gz.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151740):
https://lists.openembedded.org/g/openembedded-core/message/151740
Mute This Topic: https://lists.openembedded.org/mt/82795751/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
