You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've started looking at the recently added benchmarks to check that this crate is returning correct results and not cheating. Some differences so far (these come from looking at the postgresql debug):
Our symbol map doesn't use the symbol length, so we return a result for data in between symbols. It's unclear if this matters in practice.
If an inlined function is missing a name, we fall back to using the symbol table. llvm-addr2line prints ?? for these. An alternative is to use the name of the function where the inlining occurred.
For non-inlined functions, llvm-addr2line gives preference to the name from symbol table over the DWARF. I disagree with this. An example of where this occurs is when a function has been split into disjoint address ranges, such as name and name.cold.
The text was updated successfully, but these errors were encountered:
I've started looking at the recently added benchmarks to check that this crate is returning correct results and not cheating. Some differences so far (these come from looking at the postgresql debug):
name
andname.cold
.The text was updated successfully, but these errors were encountered: