| Re: Problems with Keil debugger vs. Forth |
|
 |
|
 |
|
 |
|
 |
Group: comp.lang.forth · Group Profile
Author: Jim GranvilleJim Granville Date: Jan 29, 2007 11:17
rickman wrote:
>
> I was using the "Locals" watch window for most of the variables since
> this was automatic. But once in awhile some of the local variables
> would seem to take on absurd values. I could not find anything in my
> code that was doing it. I dug into the disassembly listing and found
> that local variables and the parameter passing was being done in
> registers rather than on the stack. So when another routine was
> called, the variables were moved to other registers to free up the
> standard parameter regs.
That sounds inefficent..
> At this point the debugger would lose track
> and report the new value in the old register as the variable that had
> been moved to the new register. I could use a standard watch window
> to show the correct value, but this was a PITA since every routine had
> its own copy of this variable and I would have to type it in again
> when exiting or entering another routine. This is a pretty major bug
> in the Keil tools in my opinion. I don't know if this is limited to
> the ARM or the CM3 or if it is common to their combined ARM and Keil
> tool set.
Sounds to me like a std issue, where the relatively flat-scope of the
debugger, is simply unable to keep up with the compiler gymnastics.
Likely to me more of a problem, on a processor without direct memory
opcodes, as it does have to juggle the registers.
Have you tried different compiler settings ?
Most debuggers I've used have some sort of lifetime / interrupt
interaction at the detailed level - the only time you can truly
trust them, is when the debug kernal is not active :)
- so if I'm looking for a specific bug, I'll use breakpoints
over single stepping, for example. (or the simulator, depends on the
bug; Sim/debug often have large amounts of common code/mindsets, so in
your specific problem, I'd guess the Sim does the same thing )
You can also create trace-memory yourself, where you write operation
tags/trace values - yes, a pain as it is another step, but it does
remove the unknowns of the debug portion.
> The contest rules say the submission has to be done using the Keil
> tools.
An interesting restriction. Have you asked them just why that is imposed ?
It would be more widely informative, if your contest entry could be made
as both the forth version, and the forth-to-C version, with porting
comments.
Did your forth version get fully debugged ?
-jg
| 
