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 
I can't count how many times I've seen that sort of bug report, too.
If there's no debug info, the user won't be able to do anything but step around in disassembly, view memory and registers. He can't be fooled by the debugger there.
The difficulty is with the in between scenarios: optimized code--anywhere from minimal to extreme; rich vs primitive symbolics format. It's a big gray zone, and often, it's impossible for the debugger to know where along that gray zone the user is, or if he's in the gray zone at all (e.g., do compilers insert any indicator in object code that reveals the code is optimized? My guess is no, though I wouldn't be surprised to find out some do).
So, much like Chloe cracking a 128-bit encrypted file on 24 in between commercials, having a debugger reliably provide some sort of confidence level to the user is an exciting idea, but not practical to implement. Again, as a debugger provider rarely has full control over the compiler technology, there's not much the debugger can guarantee. 

I've never met a debugger I fully trust :-)

John

At 03:06 PM 6/9/2006, Chris Recoskie wrote:

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


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

Back to the top