rickman
gmail.com> wrote:> 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.
This is completely normal. The procedure call standard actually specifies
that argument/result/scratch registers.
On something like x86 usually everything goes via the stack however most
major procedure call standards for it also allow passing arguments via
registers. MS call this FASTCALL and it doesn't really have name under GCC
but is just attribute which can be applied to a function via a GCC language
extension.
> So when another routine was
> called, the variables were moved to other registers to free up the
> standard parameter regs. 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 don't quite see what you are getting at here, are you saying that you
inspecting the value in a register window or in a locals window? Are you
stepping at source level or instruction by instruction? If you are stepping
through function prologues and epilogues at machine code level you can't
expect the debugger to show the correct values until you've actually stepped
into the new function.
> 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.
Again I don't understand is this a local automatic variable to the function
or has the conversion from forth created a load of variables at global scope
or something? Or is it a parameter to the function which you are
manipulating?
If it actually is showing the wrong value for a local then this is a debug
illusion problem and please file a bug.
> I also found that in at least one case a local variable could not be
> monitored at all!
Are you sure the variable had not been optimised away? Specifing any
optimisation may impair the debug view, this is minimised at -O0 and -O1
will give a fairly good debug view.
> All in all I am not a fan of the Keil tools at this point and I don't
> think I am very happy with embedded C development.
I think that you are just expecting far too much from a C debugger. You can
not compare a language where you are patching words into a runtime where the
debugger is essentially part of that runtime to a statically compiled
language where the debugger must essentially undo the compilation with the
help of debug information.
-p
--
"Unix is user friendly, it's just picky about who its friends are."
- Anonymous
--------------------------------------------------------------------
