- Sun May 24, 2015 11:19 am
#18316
jcmvbkbc wrote:cal wrote:Backtracing seems to be not so easy without an FP but it would be nice if it just aborts
instead of being stuck in a loop
Ok, I'll take a look.
Moin,
that gdb backtracking stuff is really a mind twister for me.
But I think I found the reason why backtracking stops for me.
It's a bug in the prologue handling function IMHO.
When the optimizer moves code into the function prologue the line number information may be interleaved:
Code: Select alluart0_rx_intr_handler:
.LFB6:
.loc 1 201 0
.LVL7:
addi sp, sp, -16
.LCFI2:
s32i.n a12, sp, 8
mov.n a12, a2
.LVL8:
.loc 1 208 0
l32r a2, .LC14
.LVL9:
.loc 1 201 0
s32i.n a0, sp, 12
.loc 1 208 0
memw
l32i.n a3, a2, 0
.loc 1 201 0
s32i.n a13, sp, 4
s32i.n a14, sp, 0
.loc 1 208 0
You see code of line 201 and line 208 being interleaved.
In call0_analyze_prologue the following is used
Code: Select allprologue_sal = find_pc_line (start, 0);
if (prologue_sal.line != 0) /* Found debug info. */
body_pc = prologue_sal.end;
That means the analysis stops at .LVL8 and so misses the necessary part at .LVL9.
I thought skip_prologue_using_sal could be used to fix the problem but
as far as I see it does stop at the FIRST non prologue line, but what we need is the LAST code
OF the prologue line.
I am not sure if its a problem of the compiler or of gdb.
When adding
Code: Select all // try to catch a little bit more of prologue because optimizer may have moved code
// into prologue so that body_pc is too small when just dwarf info directly.
// TODO: find better solution!
body_pc += 6;
to the if statement above i get a better stacktrace:
Code: Select all(gdb) bt
#0 gdb_breakpoint () at arch_esp8266.c:19
#1 0x401046ae in uart0_rx_intr_handler (para=0x3fffde28) at uart.c:216
#2 0x4000050c in ?? ()
#3 0x4000050c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Do we need a variant of skip_prologuexxx that does a lilltle bit of "look ahead" to find
max(end) of the sym entries of the same line that follow in the next N symtab entries?
Is there a sensible value for N?
Cal
P.S.
0x4000050c is obviously an address in the ROM in function:
Code: Select all4000048c g F *ABS* 00000000 _xtos_l1int_handler Unfortunately gdb does not use the symbol from the executable.
My guess is that its because its an absolute symbol. global/local seems not to make a difference.
The following works as seen above:
Code: Select all40104678 l F .text 000000c1 uart0_rx_intr_handler Does anybody know of a way to fake/add ROM symbols to an executable using tools from the GNU tool chain?
I think I could hack it using elfsh but would prefer some gcc/gas/gld/objcopy hackery.
