Differences from LLVM output

[philipc]

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):

• Missing the discriminator (Handle discriminators #319). This is easy to add, but a breaking change. Additionally, the discriminator is intended for use in profile-based optimization, and interpretation of the discriminator can generally only be done by the compiler, so users are unlikely to want it.
• 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. Fixed in bin: prefer symbol table names over DWARF names #332
• 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. Fixed in bin: prefer symbol table names over DWARF names #332

[gdh1995]

The 4th point is also what I met in #326 (comment) .

[philipc]

Point 2 (not using symbol length) is likely the cause of the problem in esp-rs/espflash#600, so it looks like it does matter and should be fixed.