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. 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196377): https://lists.openembedded.org/g/openembedded-core/message/196377 Mute This Topic: https://lists.openembedded.org/mt/104619206/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
