Discuss here different C compiler set ups, and compiling executables for the ESP8266

User avatar
By cal
#18377
jcmvbkbc wrote:
projectgus wrote:
cal wrote:gcc/gas/gld/objcopy hackery.


I have also wanted this. jcmvbkbc's esp-elf-rom is useful but gdb tries to load it as a new image. I don't have a solution yet either, there must be a straightforward way though.

You can load your main image as usual and then use add-symbol-file bootrom.elf 0x40000000 to add symbols for ROM.


Would it improve something if the symbols were tagged as ".type @function"?

What do you think about marking the indirect references as objects so that they are not disassembled?

Code: Select all_r_40000094 = 0x40000094 - 0x40000000 + _stext
.global _r_40000094
.type _r_40000094,@object
.size _r_40000094,4
# get back into "code" mode
_r_40000094_end = _r_40000094 + 4
.type _r_40000094_end,@function


I added those in my experiments for all l32r and similiar that reference a symbol with offset.
Strangely enough the the disasm output uses blocks of 3 bytes but I find that still easier to grasp then
wrong instructions.

Cal
User avatar
By cal
#18448 Moin,

when executing "call" an assertion failed:

Code: Select all(gdb) call xthal_get_ccount ()
.../esp-open-sdk/crosstool-NG/.build/src/gdb-7.5.1/gdb/regcache.c:602: internal-error: regcache_raw_read: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.


Main reason for this is that call_abi seems not to be set to Call0Abi.
For testing I just changed the instantiation code in the macro.

It does not run then but hangs: (Note that I added some more trace statements)

Code: Select all(gdb) set debug xtensa 5
(gdb) call xthal_get_ccount ()
(trace) xtensa_alloc_frame_cache ()
(trace) call0_analyze_prologue (start = 0x4025aa2c, pc = 0x4025aa2c, ...)
(verb ) [call0_analyze_prologue] end_pc = 0x4025aa31
(verb ) [call0_analyze_prologue] using skipped dwarf debug info, body_pc = 0x4025aa31
(verb ) [call0_analyze_prologue] pc = 0x4025aa2c, body_pc = 0x4025aa37
(verb ) [call0_analyze_prologue] stopped at instr addr 0x4025aa2c, succeeded, body_pc 0x4025aa2c
(trace) xtensa_pseudo_register_read (... regnum = 50 (psintlevel) ...)
(trace) xtensa_register_read_masked (reg "psintlevel", ...)
(trace) xtensa_pseudo_register_read (... regnum = 51 (psum) ...)
(trace) xtensa_register_read_masked (reg "psum", ...)
(trace) xtensa_pseudo_register_read (... regnum = 52 (psexcm) ...)
(trace) xtensa_register_read_masked (reg "psexcm", ...)
(trace) xtensa_pseudo_register_read (... regnum = 53 (litbaddr) ...)
(trace) xtensa_register_read_masked (reg "litbaddr", ...)
(trace) xtensa_pseudo_register_read (... regnum = 54 (litben) ...)
(trace) xtensa_return_value(...)
(trace) xtensa_push_dummy_call (...)
(info ) [xtensa_push_dummy_call] nargs = 0, abi = 1
(info ) [xtensa_push_dummy_call] sp=0x3ffffe90, struct_return=0, struct_addr=0x0
(trace) xtensa_push_dummy_call (debug done)
(trace) xtensa_push_dummy_call (align_down)
(trace) xtensa_push_dummy_call (align_down done, call_abi=1, sp=0x3ffffe90, osp=3ffffe90, call0abi=1)
(info ) [xtensa_push_dummy_call] simulate call0
(info ) [xtensa_push_dummy_call] set new sp
(info ) [xtensa_push_dummy_call] return
(trace) xtensa_breakpoint_from_pc (pc = 0x40103cd8)


Enough for the day!

Bye,
Cal
User avatar
By projectgus
#18461
jcmvbkbc wrote:"The first non-prologue instruction" does not always mean the prologue code is over. I didn't put any unnecessary blockage after the prologue and before epilogue to allow for better instruction scheduling, and from my observations optimization passes often mix prologue instructions with the function code.


Derp, of course! That was the whole point wasn't it? Sorry.

gdb/arm-tdep.c has some illuminating comments about this problem on ARM and uses a similar fix. Cal, I think something like this may be good:

Code: Select all   if (prologue_sal.line != 0) /* Found debug info.  */
-    body_pc = prologue_sal.end;
+    body_pc = prologue_sal.end + XCHAL_MAX_INSTRUCTION_SIZE * 5; /* allow for optimiser reordering */


"5 instructions" is a bit arbitrary, I just got that number from the ARM comment! Maybe a smaller number is better, idk.

The key to setting it here is that the following lines will still limit body_pc so it doesn't extend into the next symbol, or past the PC if the PC is known.

It still seems "buggy" to me that the prologue debug info indicates an earlier end instruction to the "real" last prologue instruction, but it seems like this is just a limitation of DWARF.
User avatar
By jcmvbkbc
#18555
cal wrote:Would it improve something if the symbols were tagged as ".type @function"?

Don't know. What effect do you expect?

cal wrote:What do you think about marking the indirect references as objects so that they are not disassembled?

Code: Select all_r_40000094 = 0x40000094 - 0x40000000 + _stext
.global _r_40000094
.type _r_40000094,@object
.size _r_40000094,4
# get back into "code" mode
_r_40000094_end = _r_40000094 + 4
.type _r_40000094_end,@function


I added those in my experiments for all l32r and similiar that reference a symbol with offset.
Strangely enough the the disasm output uses blocks of 3 bytes but I find that still easier to grasp then
wrong instructions.

So you're trying to get correct disassembly when objdump or gdb run out of sync with the code because of literals or alignment, right? Normally xtensa tools use .xt-prop section that denotes extended basic block boundaries. It's not in the binutils mainline, I need to forward-port it.