[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] local variables view modes
|
I agree. However it is possible to indicate to the user that things are
likely to be suspect. E.g., if you load an executable with partial
symbolics or no debug info whatsoever, it doesn't hurt to tell the user
something like "It looks like your code is optimized, values displayed in
the debugger may not be valid," and then leave it up to the user to figure
out what is and is not right.
And no, I'm not asking for an animated paperclip to tell the user this :-P
I know it sounds silly to even think about informing users of this, as it
almost seems redundant. It seems logical that loading binaries without full
debug info will result in less than a less than perfect debugging
experience. You'd be surprised though at how many bugs I've seen though
filed by users complaining about debugger behaviour, and ultimately you
find out they were debugging an optimized program and things were behaving
exactly as intended.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
John Cortell
<john.cortell@fre
escale.com> To
Sent by: Device Debugging developer
dsdp-dd-dev-bounc discussions
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>, Device
Debugging developer discussions
<dsdp-dd-dev@xxxxxxxxxxx>
09/06/2006 03:55 cc
PM
Subject
Re: [dsdp-dd-dev] local variables
Please respond to view modes
Device Debugging
developer
discussions
<dsdp-dd-dev@ecli
pse.org>
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
