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

User avatar
By jcmvbkbc
#18556
cal wrote: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.

Yes, am also getting similar assertion failure in mere bt. Will look at it.

I've published binutils-gdb-xtensa repository here: https://github.com/jcmvbkbc/binutils-gdb-xtensa
Please report binutils and gdb issues there, it seems a bit easier to track than forum posts.
User avatar
By cal
#18572
jcmvbkbc wrote: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.


Ack.
So the feature exists, but not in esp open sdk gdb?
Is that a bfd improvement? Objxxx?

Can you explain briefly the state of/differences of state between:

Mainline binutils? (Thats official gnu dist i guess?)
Esp-open-sdk binutils?
You repo?

What should we use
for general esp8266 compilation?
for debugging with gdb?

I don't want to waste time.

Spacibo,
Cal
User avatar
By jcmvbkbc
#18574
cal wrote:So the feature exists, but not in esp open sdk gdb?
Is that a bfd improvement? Objxxx?

AFAICS it's in the objdump.
cal wrote:Can you explain briefly the state of/differences of state between:

Mainline binutils? (Thats official gnu dist i guess?)
Esp-open-sdk binutils?
You repo?

'mainline' that I'm referring to is the official binutils-gdb git repo: https://sourceware.org/git/gitweb.cgi?p ... ls-gdb.git
esp-open-sdk: certain mainline binutils and gdb releases (2.24 and 7.5.1 are selected in esp8266 config) + crosstool-NG generic patches (usually backports from mainline) + xtensa-specific patches (backports from mainline as well; not all, only essential bugfixes).
My repo: master branch + all tags from the mainline binutils, feature branches for xtensa (usually quickly merged into the mainline when done).

cal wrote:What should we use
for general esp8266 compilation?
for debugging with gdb?

What's easier. esp-open-sdk, I guess. If you need specific patches that are WiP in my tree you can either export these patches and put them into the crosstool-NG/local-patches or build entirely from my tree.

I'm also not sure if esp-open-sdk tracks the latest crosstool-NG or some specific version of it. But anyway updating it to the latest should be rather straightforward.
User avatar
By cal
#19028
jcmvbkbc wrote:
projectgus wrote:I think having body_pc set to "the first non-prologue instruction" is actually what you want, isn't it? Because the loop that scans instructions has "ia < bodypc" as the terminating condition, so it won't scan the instruction at bodypc, just all the instructions preceding it.

For my 2c, I think this is possibly a compiler bug if the DWARF information doesn't correctly identify the end of the prologue, but I don't know enough about gcc and optimisations to say for sure. Fixing it in gdb seems like a good idea, regardless.

"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.


Is it possible to say what maximum of code may get inbetween prologue parts so that we can add a raw offset
to value from dwarf debug information?
"+6" was enough for me up to now, I think angus mentioned 5*MAX_SIZE_OF_ESP8266_INSN which would make a +15
I think.
Adding that offset is a hack but it improves backtraces.
A real fix may involve scanning debug info for the prologue entry with greatest end position.
For me the hack currently is good enough.

Cal