I. probe the stack frame structure The original idea is to unwind the function call stack according to a determined prologue on the begin of a frame. For example:
-------
PC
-------
LR
-------
SP
-------
FP
-------
.......
The precondition of this idea is that every frame stores all these infomations in same order at the front of the frame. But the practices tell us that‘s not true. In fact, some functions do so, some not. Why do some functions not do so? (Not understand till now. Maybe in order to save some memery, maybe it is not necessary to do so, maybe other unknown reasons.)
To prove this jugement, we did following things.
1. The output call stack is not complete with the method refered above.
2. Produce coredump file, then analyze the frame structures with gdb. We found three strange things:
1st, the caller frame of the frame before the signal process frame is itself, so we can‘t unwind to inner frame.
2nd, in stack memery we can‘t find any frame address showed by "info frame" command. How so?
3rd, then we dissamble different frames, we were astonished to found that different functions push very different registers to the stack, even some functions didn‘t push any register at all.
3. Finally, we found an offical hint on gdb web site: "whether each function has a frame pointer and if not".
II. Try with backtrace of glibc. Since there is not a determined frame structure, can the backtrace function of glibc work? We did a lot of tries. But the results are the same with the above method. We are so wondering. So we read the source code of backtrace function of glibc-linaro. The answer is it use the same method we did before. So the results are same.
III. Try with unwind library first time. Search on google and baidu. We found a library unwind. It‘s the library to unwind function call stack. And we integrated it in our project immedially. Soon we got the result. It only has one frame more than the backtrace function, and there is some other unkown error messages. It seems not suit to our project still. We guess, maybe our project is more complicated than libunwind can apply, because we have 64bit CPU and OS, but 32bit application. Or maybe it‘s not suitable for EABI.
IV. Try to learn from GDB. Hitherto, the only one practicable method is GDB, why not to find the method that GDB use? Factually, She gong and I had tried to read GDB‘s code before. But had to terminate for it‘s too complicated and too big to understand in a short time. This time, we returned to it again. Though we didn‘t understand how it unwind the stack still, we found some usefull infomations. 1. GDB use ptrace to get the registers. 2. GDB try to parse the function prologues when there isn‘t frame pointer. But how and what‘s the criteria, we didn‘t know still.
V. Try with unwind library second time. During we try to understand GDB‘s unwinding method. We found a usefull infomation that .eh_frame or .ARM.exidx or .ARM.extab section in elf file can help to unwind the stack. This inspired a sparkle: can we unwind stack only with these section? We tried to find a way and found the attachment document. It introduced these sections and the compile paramter "-funwind-tables" and the related libunwind. So we try according it. It works!
[References]:
https://wiki.linaro.org/KenWerner/Sandbox/libunwind?action=AttachFile&do=get&target=libunwind-LDS.pdf
https://sourceware.org/gdb/papers/unwind.html
https://www.airs.com/blog/archives/460
https://www.facebook.com/notes/scott-tsai/%E5%9C%A8%E6%B2%92%E6%9C%89-frame-pointer-%E7%9A%84%E6%83%85%E6%B3%81%E4%B8%8B%E9%80%B2%E8%A1%8C-stack-unwind/784226238316104/
[A sparkle]:
Can we use _Unwind_Backtrace() of ligcc_s.so to unwind the function stack?
，