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] -=-=-=-=-=-=-=-=-=-=-=-