ESP8266 Community Forum

- Sun May 31, 2015 10:05 am #19042

Maybe I wasn't clear but I applied the same change (without condition) to the esp open sdk version and it just hung up.

I've noticed the hangup part, but absolutely missed the change ):
I'm doing my tests with QEMU gdb stub, it's very predictable.

* the litben issue is fixed.
* "call" seems to have an issue on my stub not continuing properly
* I added angus bt fix and my prologue hack to improve bt

The first is in the mainline already. The second is not in gdb. Ok, let me take a closer look at the third.
Thanks for your testing and feedback.

- Sun May 31, 2015 1:23 pm #19052 Moin,

I am confused what state the debugger should see after executing

Code: Select allasm("break 0,0");

On IA64 the PC is set after the breakpoint when entering the debugger.
On esp8266 technically the PC (epc) will be set on the breakpoint address.
If I try to imitate the ia64 and automatically increment the PC the backtrace bt does break.

So I see 2 alternatives

* I forgot to adjust some other register(s)
* xtensa is different and will show pc on the breakpoint address in debugger

And if I execute a "continue" then, will the debugger continue AFTER the breakpoint or trigger the breakpoint again?
After the breakpoint would mean an implicit "set $pc += 3" as far as I see.
Will the registers shown in gdb have debugcause/intlevel/excm etc. being set to values of the break
or to values before the break so that the effects of the break are not visible or
only partly visible?

I am confused because I try to implement "call" support and can't see how
to combine that with "break" support.

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Sun May 31, 2015 1:39 pm #19054

I am confused what state the debugger should see after executing

Code: Select allasm("break 0,0");

On IA64 the PC is set after the breakpoint when entering the debugger.
On esp8266 technically the PC (epc) will be set on the breakpoint address.
If I try to imitate the ia64 and automatically increment the PC the backtrace bt does break.

So I see 2 alternatives

* I forgot to adjust some other register(s)
* xtensa is different and will show pc on the breakpoint address in debugger

And if I execute a "continue" then, will the debugger continue AFTER the breakpoint or trigger the breakpoint again?
After the breakpoint would mean an implicit "set $pc += 3" as far as I see.
Will the registers shown in gdb have debugcause/intlevel/excm etc. being set to values of the break
or to values before the break so that the effects of the break are not visible or
only partly visible?

Debug exception is in all regards just another exception. That means
- epc<debug level> points to break instruction;
- eps<debug level> saves ps state right before break execution.
Debugcause is updated by the break instruction, reflecting that it was break (or break.n) instruction that caused the exception.
If you don't adjust epc<debug level> before returning from handler you'll return back to break and immediately get debug exception again (if eps<debug level> wasn't changed so that cintlevel would be >= debuglevel after return).

Normally an instruction pointed to by epc<debug level> should be analyzed before returning from the debug exception and in case it's break/break.n it should be stepped over.

BTW, did you mean IA64 or x86_64 aka amd64 aka x64? They are significantly different.

- Sun May 31, 2015 1:50 pm #19055

BTW, did you mean IA64 or x86_64 aka amd64 aka x64? They are significantly different.

Sorry, you are right: x64 is what I meant.

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG