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

Reply via email to