https://bugs.kde.org/show_bug.cgi?id=445668
--- Comment #1 from Mark Wielaard <m...@klomp.org> ---
(In reply to Nick Nethercote from comment #0)
> Here is some DHAT output I am getting with Rust code:
>
> > └── PP 1.14/14 {
> > Total: 118,312 bytes (0.05%, 60.74/Minstr) in 11,864 blocks
> > (1.12%, 6.09/Minstr), avg size 9.97 bytes, avg lifetime 60,918.19 instrs
> > (0% of program duration)
> > Max: 40 bytes in 5 blocks, avg size 8 bytes
> > At t-gmax: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> > At t-end: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> > Reads: 178,976 bytes (0.03%, 91.89/Minstr), 1.51/byte
> > Writes: 130,464 bytes (0.05%, 66.98/Minstr), 1.1/byte
> > Allocated at {
> > #1: 0xA2D0172:
> > _RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694
> > (alloc.rs:87)
> > #2: 0xA2C42B2:
> > _RINvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB6_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE19process_obligationsNtB1s_16FulfillProcessorINtB6_7OutcomeB1q_NtNtCsgI90OQiJWEs_11rustc_infer6traits20FulfillmentErrorCodeEEB1w_
> > (mod.rs:459)
> > #3: 0xA27EA42:
> > _RNvMs_NtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfillNtB4_18FulfillmentContext6select.llvm.5302840341462405287
> > (fulfill.rs:140)
> > }
> > }
>
> Here's what it should look like:
>
> > └── PP 1.14/14 {
> > Total: 118,312 bytes (0.05%, 60.81/Minstr) in 11,864 blocks
> > (1.12%, 6.1/Minstr), avg size 9.97 bytes, avg lifetime 60,857.47 instrs (0%
> > of program duration)
> > Max: 40 bytes in 5 blocks, avg size 8 bytes
> > At t-gmax: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> > At t-end: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> > Reads: 178,976 bytes (0.03%, 91.99/Minstr), 1.51/byte
> > Writes: 130,464 bytes (0.05%, 67.05/Minstr), 1.1/byte
> > Allocated at {
> > #1: 0xA2CD172: alloc (alloc.rs:87)
> > #2: 0xA2CD172: alloc_impl (alloc.rs:169)
> > #3: 0xA2CD172: allocate (alloc.rs:229)
> > #4: 0xA2CD172: exchange_malloc (alloc.rs:318)
> > #5: 0xA2CD172:
> > new<rustc_trait_selection::traits::fulfill::PendingPredicateObligation>
> > (mod.rs:192)
> > #6: 0xA2CD172:
> > _RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694
> > (mod.rs:376)
> > #7: 0xA2C12B2:
> > _RINvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB6_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE19process_obligationsNtB1s_16FulfillProcessorINtB6_7OutcomeB1q_NtNtCsgI90OQiJWEs_11rustc_infer6traits20FulfillmentErrorCodeEEB1w_
> > (mod.rs:459)
> > #8: 0xA27BA42:
> > _RNvMs_NtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfillNtB4_18FulfillmentContext6select.llvm.5302840341462405287
> > (fulfill.rs:140)
> > }
> > }
OK, so we (should have) have 6 frames all (inlined) all at the same address,
inside a function (we cannot demangle?)
Inline information comes from the DIE tree, so it makes sense that it is
related to this commit:
> I bisected the problem to this commit:
>
> commit 75e3ef0f3b834f75f49333d35b5a040060247b03
> Author: Mark Wielaard <m...@klomp.org>
> Date: Thu Sep 16 22:01:47 2021 +0200
>
> readdwarf3: Skip units without addresses when looking for inlined
> functions
>
> When a unit doesn't cover any addresses skip it because no actual code
> will be inside. Also use skip_DIE instead of read_DIE when not parsing
> (skipping) children.
>
> Reverting this commit fixed the problem, though the reversion was a bit
> messy because some things have changed since.
>
> Mark, I don't understand much about dwarf3. Any idea what might be wrong? I
> was profiling the Rust compiler which is very large and complicated. If
> necessary, I could try to create a smaller Rust program that reproduces the
> error.
Parsing a DIE tree is somewhat expensive, so what this commit does is skip
parsing a CU DIE tree if it doesn't cover an addresses. That is if it doesn't
have a DW_AT_low_pc and/or DW_AT_ranges attribute. Such a Compile Unit doesn't
(or shouldn't) contain any entries that have addresses associated (it only
contains type information for example) and so doesn't need to be read, but can
just be skipped.
So either the compiler did not associate any addresses to the unit that
contains the function (and the inlined subroutine information) or we are not
checking the unit attributes correctly.
If you have a smaller example that would be great. Otherwise could you search
for the DIE for
"_RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694"
(*) and post the unit DIE (the first one with DW_TAG_compile_unit,
partial_unit, skeleton_unit, etc.) and if it isn't too large the whole DIE tree
for that unit?
You can use readelf (or eu-readelf) --debug-dump=info for that (but the output
is probably really large)
(*) BTW. What is this? It looks like a mangled Rust v0 symbol, but it isn't
because it (I also checked with c++filt) cannot be demangled.
--
You are receiving this mail because:
You are watching all bug changes.
