Strange debugger behavior anyone?

[TjBordelon]

To your point on self modifying code being unneeded, I have to call you on that. In my application, the XCORE is a co-processor. I am blasting over snipits of code to be run. Mind you these issues have nothing to do with this. I can think of a dozen respected designs that do this. Namely the Playstation.

Another reason is for the lack of DMA. I have tight code that copies over data from a port. Depending on the mode the data may be of a different size or need to be copied with different interleaving. I have an engine that generates code for this purpose and it does just fine. If I needed to run slow and wasn't handling video I suppose I wouldn't need to do all this.

But even still, the "self modifying code" argument is simply a point. If the debugger didn't put it there, it won't show you. Which means if the debugger is wrong, it lies to you.

But I digress... None of the above has anything to do with my original "rant" as you say.

You're breaking the ABI, and expect the debugger to notice? Heh.

I forgot to restore a stack variable. It's a bug. That's why I'm in a debugger :) Since I'm an old timer at this point with literally 10+ IDEs in my past, the disassembly window is usually where I go to find "truth". Alas that is not the case with this IDE. It won't show you what is really there. That is very dangerous IMHO and is not something I am used to in other tools.

Most people don't have these problems. Most people know how to work
around such problems just fine. Most people do not reply to rants.

If ranting is daring to find out if others have experienced this bug, I stand guilty as charged. But working around a broken disasembly window seems a bit more tolerant that I'm willing to be. That's 101 functionality that can't be compromised.

So in the end there are 2 conclusions until these issues are fixed. Again this is only true for MULTICORE MAIN as far as I am aware:

- When in main() don't expect the debugger to work. You might end up in main unexpectedly so trying to avoid debugging there can be unavoidable. (you might not realize you're there as in my case)

- The disassembly window doesn't show you what is really there.


These 2 facts alone should be helpful to others-- I wish I knew them. Hopefully this will be fixed.

[JasonWhiteman]

My experience was a breakpoint set outside of main, in a different source than top-level, did not break where expected. I'd have to go backwards to reproduce - but I believe the breakpoint was set in "uart_rc.xc".

I'm not using my own code and have not reviewed the entire source - so how it makes or breaks rules is not altogether known to me at this point.

The specific code used was the GPIO COM tutorial (app_sk_gpio_com_demo Version 1.0.4rc0). I was merely using it as a means to furthering learn the environment and also leverage code.

The debugger's stability is not a deal breaker as there are other methods to solve problems generated.

There is merit to the claims that the platform "just works" and an array of problems may be self-imposed. Part of this may be using the "wrong" toolchain for the intended stability. Of course "wrong" vs. "right" is not predetermined -- so you bump into the roadblock, reset, and pick another direction.

One interesting "poll" would be to see what the general use-case is for the population that never see problems. At the moment, I have a limited sample - but within that sample the IDE users tend to have problems and command line users tend not to.

For now, I believe XMOS is aware of the problems - should have sufficient steps to reproduce - and is working on solving your debugger issue. Seems like reasonable progress to me.

In the meantime, employ other methods. Feel free to make XMOS aware of any problems you encounter along the way, and stay positive.

Regards,
Jason Whiteman

[TjBordelon]

For now, I believe XMOS is aware of the problems - should have sufficient steps to reproduce - and is working on solving your debugger issue. Seems like reasonable progress to me.

Absolutely- they have been great with the ticket system, and I expect they'll fix it. For now I am able to work around it since I know more or less what to look for and how to recognize it.