[M3devel] A rant about llvm and debug information

[Rodney M. Bates]

On 03/14/2016 01:01 PM, Darko Volaric wrote:
> My theory about an internal debugger is that it could be (but not would be) implemented as a source to source translation. The idea is to stay within the front end and avoid these back end issues and use the compiler infrastructure rather than export debug info. Obviously some runtime extensions would be needed like storing declaration names and being able to index the elements of call frames (I guess that is a large part of debug info). This implies some (possibly serious) limitations, like having to recompile if you want to set a breakpoint and the like, but with the compilers relative speed and efficiency I do not see that as a huge problem. Obviously it's not the same as a proper interactive debugger. There would also be some performance penalties but possibly some gains too.
>
> As you say, this would probably not be what you want, but I'm wondering how much GDB functionality could be implemented this way and how useful it would be. I think it would be an enduring benefit to the compiler to have something that even approximates it, available straight out of the box.
>
> Obviously implementation effort is a big deal as usual, but I might try pinning down how it would be implemented in detail and if it could be done relatively simply. One important question is: what is the most important functionality required? Please don't say "reversing through code".
>

My brief list:

Set breakpoints, possibly before execution starts.
Stop on raise of specific or all exceptions.
Variable watchpoints (not too often, but *really* important when needed.
   (These don't always work in (m3)gdb.)
Step into, step over, finish (current procedure), continue
Backtrace, move up and down in it.
Evaluate complete M3 expressions.  This covers examining variables and
   calling function procedures.
Execute assignment statements to variables not optimized away.
Execute procedure calls, including method calls.
Refer to things in M3 terms, i.e. up-level references, qualified references, etc.
Examination/set data at machine-level, for debugging unsafe code, compiler/RTS, etc.

And, not the least by any stretch, just have things actually work reliably.  There
are several places in (m3)gdb that sometimes give incorrect output, and it can be hard
to know when to trust your debugger and when to assume it is not really telling
the truth.


For a fairly complete and much more detailed description of what m3gdb now has, see
doc/help/m3gdb/m3gdb.html in the git cm3 repository.  This also notes a number of
deficiencies of current m3gdb and describes some of the subtle problems that have
come up.

I have had a few times when reverse execution would have been very helpful, but
have managed to do without anyway, with much more trouble.  As I understand,
nobody has found an implementation that does not slow down the preceding
forward execution by order(s) of magnitude, which I would expect to greatly
reduce its utility.

-- 
Rodney Bates
rodney.m.bates at acm.org