xtensa-lx106-elf-addr2line tool not working for all exceptions

[rajkumar patel]

hi,

i want to use xtensa-lx106-elf-addr2line tool available in esp8266 RTOS SDK.
basically i'm trying to fetch the line number from the address which is held by PC(program counter) when my program crashes.
this PC content can be read from epc1 register which is basically gets printed on console in any crash situation.

i.e.
lìârFatal exception (29):
epc1=0x40102721 //pc
epc2=0x00000000
epc3=0x40100553
epcvaddr=0x00000000
depc=0x00000000
rtn_add=0x40102721

i've tested this tool xtensa-lx106-elf-addr2line for exception no 29(which is the exception which gets produced whenever we try to write into unauthorised (for example - read only) space.

i'm using command in this manner

> xtensa-lx106-elf-addr2line -e build/app1.out 0x40102721

here, build/app1.out is the path to elf file which is in build folder of our SDK and 0x40102721 is the pc content at the time of crash.

this command works fine for this particular exception, but when i try to use this tool for exception no. 28, it's not giving crash info.

if anyone has faced this issue earlier and had found any solution or any idea about how to overcome this thing, then kindly post your response.

regards.
-rajkumar patel

[pratik]

Did you try accessing the .S assembler output and search for epc1 address manually instead of using the command line tool?
SLower, but will point out faults even when they are in core sub-routines.

[rajkumar patel]

hey,
thanks for your valuable suggestion..

i've tried to go through assembly file, but it's taking time like forever...
and only idea which i'm getting from it is the function which was creating exception, but real backtracing seems to be too hard.
right now i'm working with ESP8266 RTOS SDK V1.5.0, and willing to use gdbstub for debugging purpose, but for that matter i'll be requiring another xtensa tool "xtensa-lx106-elf-gdb.exe", but the same i don't find in my xtensa toolchain of my SDK.
can i use that tool from another sort of SDK for my working sdk?
i'm willing to have more such good ideas on this debugging stuff.

thanks for your time, Pratik!

[rajkumar patel]

hi,

has anyone found sure fire method to get line number(which caused esp8266 crash) using this addr2line tool?
i checked .out file which is getting created on compile time and which is being used along with addr2line tool in situation of a crash.

in scenario where i am not able to find adequate line number from content of pc(program counter) when used with addr2line, i checked reading pc address in my app1.out file. and i found that, this entry is not present in that file. and hence , i am facing trouble to get src line number from this tool.even gdb tool which is provided in idf of esp32 in toolchain was not giving the result due to this reason only.

is there any way to get the successful result in all scenario using this tool or this is the limitation of this tool?

[rajkumar patel]

@team_esp,

kindly post your suggestions, and shade some light on feasibility of this tool so that i could go further with debugging thing, either using this tool(if you validate) or with some alternate debugging options.

thanks.

[pratik]

Sorry, no direct debugging such as JTAG debugging feature is officially supported for ESP8266. The best you can do is backtrace from the address that caused an exception. Apart from misaligned read/write or incorrect accesses, there are not a whole lot of issues with ESP8266 really.
Are you stuck with a specific issue that you are unable to solve?

[rajkumar patel]

hi pratik,

driven by my urge to have atleast one sure fire method to debug my esp8266, i had to post the query again.
it's really good to hear from you.

The best you can do is backtrace from the address that caused an exception.

this is what i'm trying to do.
the tool that i'm discussing has come out not so reliable but whenever its so accurate that's why i'm counting more on that.
i'm having several questions regarding this which i'm listing out below:
1. whatever Program counter address we're getting, would that be present in .out file ? and if not then where would it be?( i mentioned .out file as this is what i'm using along with this tool and also with the gdb tool provided inside esp32 idf)
2. earlier you have mentioned that i should go through .S file for backtracing, but i'm not sure how to do backtracing from assembly.(is there any proper way to learn this?)
3. how about GDBStub? is it that accurate and could be used instead of JTAG?(right now i'm willing to use GDBStub in my project)

right now, i'm avoiding going for JTAG option as i want to use less hardware.

best regards, Pratik.

[pratik]

To trace back from assembly file, you will need to have basic knowledge of assembly knowledge for any modern core. For example, an ARM7, ARM9 or something equivalent. Know the load/store commands, at least. That is where issues come up when working with ESP8266.

As for ESP32, it officially supports JTAG debugging, so no issues if you work with ESP32. But ESP8266 is not capable of that.
You must find issues based on fatal exception cause.

GDBstub is what we use internally, but that is to debug REALLY complex code such as communication stacks. You'd be better off using assembly files for most stuff. The issues you get are very commonly and usually limited to memory access operations and function calls. So best to just watch out for those.

As for locating which function caused an issue, just find that address in .S listing. If you cannot, find a label from preceeding addresses...
The exception address HAS to be present, right? Because it was in the program counter (PC) when exception occurred. Means you did somehow try to execute that instruction.
If you find it way too weird, say epc1 = 0x70005650... which is not even in the peripheral or memory address range... you are probably calling some function or callback whose address isn't loaded, etc.

I personally never used anything else. This method is most convenient once you get used to it.

[rajkumar patel]

Hey Pratik,
this is amazing info from your end. highly appreciated. if i get stuck with any of these, will post over here.
& thanks for your detailed response and suggestions.

best wishes and regards, Pratik.