Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] local variables view modes

This gets a little confusing as there are two things to consider. Given a PC location and a local variable in optimized code:

1. is the variable out of language scope?
2. is its representation (in a register or stack slot) intact?

These are two independent states. Some compilers+symbolics can provide neither. Some can provide one but not necessarily the other. Ideally, if the answer is YES and YES, the debugger would show the non-live variable in the "all" mode as unavailable. But ultimately, the debugger can't guarantee this across the board as our debugger ultimately deals with many combinations of compiler and symbolics format. So, in one scenario, the debugger could be "honest", but in a second it can't be, and there's no practical way to let the user know when it is and isn't being honest.

So, it seems to me that user skepticism is a must unless you have complete control over the compilers your user employs. Now, I won't argue that it wouldn't be a good idea to let the user know a dead variable's representation is unavailable when the debugger can determine that. But given that there are going to be any number of situations where the debugger can't do that, it certainly makes me question whether it's worth trying to support it in some of the cases.

John

At 01:50 PM 6/9/2006, Daniel Jacobowitz wrote:
... Unless you have a good debugger and a good compiler!  A little
skepticism never hurt anyone, but we can do far better than this
given DWARF.

For instance, recent versions of GCC will be glad to give you
reasonably accurate live range information; if the variable is dead, it
will show up as unavailable.  Of course there's times where modifying
the copy the debugger knows about will have unpredictable effects
because of another copy, but in general this works well.

I'd highly recommend that if your debugger can provide out of scope
variables, it indicate them clearly.

--
Daniel Jacobowitz
CodeSourcery
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev

Back to the top