Hi Richard,
On 28.02.24 10:14, Richard Purdie wrote:
On Wed, 2024-02-28 at 07:21 +0100, Philip Lorenz wrote:
With the introduction of debuginfod ([1]), providing debug symbols to
developers has been greatly simplified. Initial support for spawning a
debuginfod server is already available as part of poky.
However, this relies on debuginfod scraping the debug packages for their
build IDs. This is not only inefficient (as all packages need to be
extracted again), but it also does not scale well when covering a large
number of builds.
To mitigate this, we are currently working on an approach to extract the
metadata needed to provide debug symbols as part of the bitbake build.
This metadata includes the mapping of the GNU build ID to the package
holding the debug symbol. The metadata will be treated as another build
artifact and can be consumed by a daemon implementing the debuginfod
HTTP API to serve debug symbol file requests from the package feed
produced by the bitbake build.
Initially, we considered implementing the generation of debug metadata
directly as part of emit_pkgdata() in package.bbclass (disabled by
default). However, we discarded this idea as introducing a configuration
option would increase maintenance effort for a feature that would
potentially only be enabled in very few builds. Instead, we opted to
extend package.bbclass to expose the minimal information needed to
reliably identify debug symbol files, which can then be consumed by a
packaging hook.
Is this extension something that is viable to be merged? We are
considering open-sourcing the other parts needed to implement the setup
described above, but as those parts are still in the prototyping phase,
it will require some more time.
[1] https://sourceware.org/elfutils/Debuginfod.html
I think this is the kind of direction we've wanted to go in. I'm not
sure the patch as it stands is that useful as it just lists files which
you could just as easily obtain with a os.walk on the filesystem but in
principle I'd be fine with writing some extra data during do_package or
do_packagedata which saves the buildid mappings.
In one of my first iterations I placed the build ID to file mapping into
the "extended" section of "pkgdata". We'd then consume this data after
the build has finished to produce the debug info metadata database which
contains the mapping from build ID to debug symbol file and the package
containing the file. If this sounds sane to you I can clean up that
version and share it here.
So yes, in principle the idea sounds good but obviously the final
decision would depend upon the patches.
I'm assuming this data wouldn't be that large or that expensive to
compute so I'd prefer not to hide it behind extra configuration options
if we can help it. That does depend on the overheads/costs though.
I just executed build ID extraction on the debug packages of our medium
sized kirkstone based distro (see my reply to Alex for more details).
Sequentially extracting build IDs from around 8000 files took around
1:30 minutes on my machine. While I wouldn't call this excessive, I am
also not sure whether this is too much overhead given that I only expect
this data to be used in some deployments.
Br,
Philip
--
Philip Lorenz
BMW Car IT GmbH, Software-Plattform, -Integration Connected Company,
Lise-Meitner-Straße 14, 89081 Ulm
-------------------------------------------------------------------------
BMW Car IT GmbH
Management: Chris Brandt and Michael Böttrich
Domicile and Court of Registry: München HRB 134810
-------------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196392):
https://lists.openembedded.org/g/openembedded-core/message/196392
Mute This Topic: https://lists.openembedded.org/mt/104619206/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
