Bug 1929734
| Summary: | Updated bundled libbacktrace for DWARF5 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark Wielaard <mjw> |
| Component: | rust-backtrace-sys | Assignee: | Rust SIG <rust-sig> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 34 | CC: | decathorpe, fweimer, igor.raits, jistone, rust-sig |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-08 19:17:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mark Wielaard
2021-02-17 14:24:20 UTC
Not sure how we should do that? backtrace-sys crate ships libbacktrace as a git submodule: https://github.com/rust-lang/backtrace-rs/tree/master/crates/backtrace-sys/src Of a rust-lang fork of some random libbacktrace repo plus some downstream changes on top: https://github.com/rust-lang/libbacktrace/tree/5c88e094a691bb803d4bba342403a10459abad9e That fork has not been updated in a long time. So which libbacktrace should we use instead? I believe the one maintained in gcc git is what gets updated most regularly: https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libbacktrace;hb=HEAD It is at least the one that is known to work against and is tested against current GCC, so known to include all the DWARF5 fixes you'll need. FWIW, this crate is only used as one of several possible implementations for the backtrace crate (rust-backtrace rpm), but its default is to use gimli. AFAICS nothing in Fedora is building with rust-backtrace+backtrace-sys-devel that would pull this in. That said, I think this should be filed as a request on the backtrace-rs repo, and they can rebase the libbacktrace fork. I'll also note that backtrace-sys is vendored in the sources for the rust toolchain itself, and it was used until rust-1.46.0, but 1.47 also switched to the gimli backend. Mark, for Rust's sake you might want to investigate how gimli fares with DWARF5, but AFAIK it should be supported. https://github.com/gimli-rs/gimli (In reply to Josh Stone from comment #3) > Mark, for Rust's sake you might want to investigate how gimli fares with > DWARF5, but AFAIK it should be supported. https://github.com/gimli-rs/gimli Gimli does handle most of DWARF5, but not DWARF Supplementary Object Files, which is what dwz produces (well, it produces the GNU extension for DWARF4, but it is very similar). Since Fedora uses dwz for everything using gimli is probably not a good default provider. Upstream has removed backtrace-sys: https://github.com/rust-lang/backtrace-rs/pull/423 I suppose Fedora could still patch in newer libbacktrace changes, but I expect this package will simply be retired. (In reply to Mark Wielaard from comment #4) > Gimli does handle most of DWARF5, but not DWARF Supplementary Object Files, > which is what dwz produces (well, it produces the GNU extension for DWARF4, > but it is very similar). Since Fedora uses dwz for everything using gimli is > probably not a good default provider. It seems gimli does support this now, and it's in progress for backtrace-rs: https://github.com/rust-lang/backtrace-rs/issues/410 I've updated backtrace to version 0.3.59, which drops the backtrace-sys dependency entirely: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ed82cab46e I will soon retire the rust-backtrace-sys package in rawhide, rendering this bug obsolete. |