espflash monitor addr2line is different compared to native add2line

[Scott Mabin]

Consider the hello world esp32 example startup:

load:0x3fff0030,len:7104
load:0x40078000,len:15576
load:0x40080400,len:4
0x40080400 - _DoubleExceptionVector
    at ??:??
ho 8 tail 4 room 4
load:0x40080404,len:3876
0x40080404 - _DoubleExceptionVector
    at ??:??
entry 0x4008064c
0x4008064c - __user_exception
    at /home/mabez/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-backtrace-0.10.0/src/lib.rs:113

If you actually call addr2line on with these addresses you don't get the same output for the first two entries.

xtensa-esp32-elf-addr2line -a 0x40080400 -e target/xtensa-esp32-none-elf/debug/examples/hello_world
0x40080400
??:0

xtensa-esp32-elf-addr2line -a 0x40080404 -e target/xtensa-esp32-none-elf/debug/examples/hello_world
0x40080404
??:0

Though I would argue that espflash is right here (take a look at https://github.com/esp-rs/xtensa-lx/blob/d6b8224d8a3e426be3564481130d994fe73e2bf6/xtensa-lx-rt/exception-esp32.x.jinja#L91-L93) this creates a confusing log where users think that some exception is occurring.

I think somehow we want to avoid this behaviour, but I don't know the best way to approach this.

cc: @bjoernQ I think you poked around in this bit of code last, any suggestions?

[Björn Quentin]

I remember it gives random results if the address doesn't make any sense (e.g. the address doesn't even match any segment)

I think @bugadani suggested to not print in yellow. Maybe we shouldn't color that output at all. E.g. when printing the back trace of an exception it should be in red. The addresses fron the ROM bootloader probably shouldn't colored at all. Still might confuse users but maybe it doesn't look that concerning

[Dániel Buga]

espflash is absolutely not correct interpreting 0x40080400 as _DoubleExceptionVector. The vectors are 0x40080000 .. 0x40080400, the upper address is the beginning of iram_seg. I think addr2line in espflash is just trying to print the previous symbol that it can find.

[Björn Quentin]

Besides the fact addr2line seems to be incorrect sometimes, it probably even doesn't make sense trying to resolve addresses at that stage since we are about to load the 2nd stage bootloader here. Resolving the addresses don't make much sense.

To make it even harder: if the ROM code prints the last seen PC, resolving it is most probably helpful

Maybe we shouldn't try to resolve everything that looks like an address? Maybe have a special syntax to mark something as a resolvable address? (like @0x0x4007ad0) Would be easy to adapt esp-backtrace etc. but would it hurt std?

We could try to be clever by "knowing" what the bootloaders print but that's a can of worms - latest when dealing with other bootloaders

But that's not really what the issue is about - how can we improve the results of addr2line? We already added a check if an address is in the range of some segment in the elf ... probably we can add an additional check there. I'll have a look

Or maybe have a look at probe-rs?

[Dániel Buga]

But that's not really what the issue is about - how can we improve the results of addr2line? We already added a check if an address is in the range of some segment in the elf ... probably we can add an additional check there. I'll have a look

Before you go down a rabbit hole, the issue is not that the address is necessarily in a wrong segment (you may very well be interested in code placed to iram_seg), but that the symbol addr2line finds is in a different one. Other than that I think the idea is a useful starting point.

[Björn Quentin]

#603 should make things better

But still, I think

• we shouldn't colorize the resolved addresses ... it's needlessly asking for attention and the printing code knows why it's choosing a color or not
• we should not resolve addresses in lines like load:0xXXXXXXXX,len:X and entry 0xXXXXXXXX since that will never be correct - and since it's ROM code printing this shouldn't change