ESP8266 Community Forum

- Sun May 31, 2015 2:08 pm #19057

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.

Your register explanation meats my expectations.

I did an implicit "set $pc +=3" (resp. 2) at some time but got unsure because when I connected that
to eclipse cdt that does an automatic continue so I disabled the increment of pc.

OK, will add that again.

When I continue after a break I do that via "rfi 2" and that works as expected.

When a "call xxx()" is executed via gdb registers "A0","A1" and "PC" are set, hw breakpoint is set to "A0" address and then a "continue" is done.
I can't see a difference from a simple continue so "rfi 2" is executed. That lowers intlevel and interrupts happen
while the "xxx" function is being executed.
Is that expected behavior?
I couldn't find out yet, why the hw breakpoint does not trigger the stub again but the interrupt level and the use of
"rfi 2" does confuse me.

Thanks for your patience,
Cal

Get your modules here:

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

- Mon Jun 01, 2015 7:13 am #19111

I did an implicit "set $pc +=3" (resp. 2) at some time but got unsure because when I connected that
to eclipse cdt that does an automatic continue so I disabled the increment of pc.

In the gdbserver I made for another xtensa setup a while ago I did the following:
https://github.com/jcmvbkbc/gdbstub-xte ... ntry.S#L46

When I continue after a break I do that via "rfi 2" and that works as expected.

When a "call xxx()" is executed via gdb registers "A0","A1" and "PC" are set, hw breakpoint is set to "A0" address and then a "continue" is done.
I can't see a difference from a simple continue so "rfi 2" is executed. That lowers intlevel and interrupts happen
while the "xxx" function is being executed.
Is that expected behavior?

Sounds right. If the user wants to disable interrupts he can change PS before continuing/calling function.

- Mon Jun 01, 2015 7:26 am #19113

I did an implicit "set $pc +=3" (resp. 2) at some time but got unsure because when I connected that
to eclipse cdt that does an automatic continue so I disabled the increment of pc.

In the gdbserver I made for another xtensa setup a while ago I did the following:
https://github.com/jcmvbkbc/gdbstub-xte ... ntry.S#L46

I will take a look.

When I continue after a break I do that via "rfi 2" and that works as expected.

When a "call xxx()" is executed via gdb registers "A0","A1" and "PC" are set, hw breakpoint is set to "A0" address and then a "continue" is done.
I can't see a difference from a simple continue so "rfi 2" is executed. That lowers intlevel and interrupts happen
while the "xxx" function is being executed.
Is that expected behavior?

Sounds right. If the user wants to disable interrupts he can change PS before continuing/calling function.

Ohh, yes. I copy PC to EPC2 but should do the same for PS .....

Get your modules here:

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

- Mon Jun 01, 2015 7:59 am #19116

I did an implicit "set $pc +=3" (resp. 2) at some time but got unsure because when I connected that
to eclipse cdt that does an automatic continue so I disabled the increment of pc.

In the gdbserver I made for another xtensa setup a while ago I did the following:
https://github.com/jcmvbkbc/gdbstub-xte ... ntry.S#L46

Looks familiar.

I tried to imitate the standard exception vector by allocating "aregs" from the stack and hiding that
from gdb but that caused most of the trouble I have with using gdb "call" and garbled the stack.
I thought about using a static regs structure before but will do it now.

Hmm but you are modifying the stack, too and doing a call to the exception handler.

Code: Select allmovi a1, stack + STACK_SIZE - 20

I have to take a closer look how that works together with gdb dummy_frame "call" handling.

Why do you clear EXCM?
Does your debug handler run with interrupts enabled?
Do you recommend that?

I was thinking that this will trigger timer interrupts etc. and that means the application is not really stopped.

Sharing the same hardware is tricky. I like it.

Thanks for your patience,
Cal

Get your modules here:

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