On Mon, 2023-11-20 at 22:53 +0000, Peter Kjellerstedt wrote: > > -----Original Message----- > > From: openembedded-core@lists.openembedded.org <openembedded- > > c...@lists.openembedded.org> On Behalf Of Adrian Freihofer > > Sent: den 15 november 2023 23:33 > > To: Christopher Larson <kerg...@gmail.com> > > Cc: openembedded-core@lists.openembedded.org > > Subject: Re: [OE-core] [PATCH v8 3/8] image-combined-dbg: make this > > the > > default > > > > On Wed, 2023-11-15 at 09:26 -0700, Christopher Larson wrote: > > > > > > Can you explain your issues with gdb with using a rootfs-dbg, > > > because > > > I don’t see any problem with a filesystem that only contains > > > debug > > > symbols, given how easily gdb can be configured to look into > > > alternate paths. I’ll admit I also don’t know the difference > > > between > > > these modes, and also wonder how IMAGE_GEN_DEBUGFS relates. > > > > > > > > It simply does not find the symbols if only the rootfs-dbg is > > available. If this class > > https://git.yoctoproject.org/poky/tree/meta/classes-recipe/image-combined-dbg.bbclass > > is added to the build it just works. > > > > Since this is not too obvious, I wondered if it wouldn't be better > > if > > the combined debugfs were the default behavior. Then Ross asked the > > same question and I developed a patch to simplify this. > > > > But either way, there are too many unanswered questions to change a > > well-established default behavior. And there are other ways to deal > > with it. > > Thank you for pointing this out. > > For what it's worth, we have local changes that more or less do this > (predating image-combined-dbg.bbclass), as we have only seen a use > case for the combined debugfs tar ball. So I was rather hoping this > would be accepted, so that we can drop our local changes... > > //Peter >
In theory, I completely agree with Christopher. That seems to be the right way to go. But I have tested this again. I am not able to configure GDB to find the sources with a split rootf + rootfs-dbg. I tried adding rootfs and rootfs-dbg in different order and with different paths to the solib search path. Stepping into libraries contained in rootfs/rootfs-dbg does not work. Maybe I did something wrong or we could consider this a bug in GDB. But with a combined rootfs-dbg this works in all the different variants I have tried. One approach to handle this is to improve GDB's solib search function to support a shared rootfs dbg. But it's not only about GDB. There are other tools which most probably have similar issues. >From a usability point of view, I would at least like to have an easy and obvious way to configure a combined rootfs-dbg for an image. It took me an infinite amount of time to figure out why GDB doesn't work and that there is an image-combined-dbg.bbclass supposed to fix that. Defaulting to a not combined rootfs-dbg and providing code in a hidden bbclass is misleading. What could also help a bit is to make the code of the image-combined- dbg.bbclass more prominent and more official e.g. by moving it into the image.bbclass and support to enable it via variable which can be documented and referred in various sections of the documentation but also in the local.conf.template. The documentation should then point out that e.g. stepping with GDB does not work until the binaries are available from the same rootfs folder as the debug symbols are. Such a patch would be a minor refactoring only. @Peter: Would this help for your use case? This would also allow the default to be changed some when in the future. The question of who needs a shared dbg rootfs for which use case, as opposed to those who struggle with simple remote debugging because of this default behavior, still seems valid to me. But I also have to say that recent documentation points out that the rootfs.tar must be extracted into the extracted rootfs-dbg which is a working solution. The issue which I have is with the SDK which tries to avoid building the tars and extracting them again just for providing the debug symbols on the host. This use case is probably new. Best regards, Adrian
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191074): https://lists.openembedded.org/g/openembedded-core/message/191074 Mute This Topic: https://lists.openembedded.org/mt/102316026/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-