[M3devel] A rant about llvm and debug information

[Darko Volaric]

I agree that nasty bugs are still possible in M3, especially in large code
bases, but I was thinking that safety avoids bugs that involve nasty things
like memory overwrites and that safety facilitates an internal debugger. I
have a bit of an "all M3" fetish, but wouldn't a compiled in, built in
debugger be a better solution given the difficulties you described as the
backend changes? I'd think it could be relatively easy to write if parts of
the compiler can be re-used (eg parsing and evaluating expressions) and
leveraged (eg compiling in breakpoints and traces).

Of course you most likely are happy with gdb and want to continue along
that path. I've wanted to add some more debugging features to the compiler
for some time.

On Sun, Mar 13, 2016 at 5:29 PM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:

> I want a better m3gdb, i.e., an interactive debugger for an executing
> program.
> Even with excellent type safety, there are plenty of algorithmic bugs that
> are not type violations.  Then with large sets of source code and large
> sets
> of data, a debugger is just so much faster than anything else.
>
> As an example, I very recently fixed a long-standing compiler bug that
> Peter
> reported.  The compiler crashed after first correctly reporting a static
> error on the code being compiled.  Figuring out what was wrong and how
> to fix all the affected cases without breaking any others required looking
> at several spots in the compiler, all unfamiliar to me.  Such as it is,
> the current m3gdb helped immensely.  For example, in many places, I saw
> in the data structure, only the compiler's internal integer-mapped
> representation
> of an identifier, I could quickly see the actual identifier with:
>
> m3gdb> print M3ID.ToText(436)
>
> But I have many pages of todo lists of fixes and improvements to make to
> m3gdb.  I had been thinking this would all be so much easier with Dwarf
> debug info.
>
> On 03/12/2016 03:02 PM, Darko Volaric wrote:
>
>> Rodney can you tell me what your motivation for this sort of debugging
>> support is? Is it for post mortem debugging, multi-language, external tool
>> support or something else? M3 is so safe I've always envisaged an
>> integrated (compiled-in) debugging tool which is in effect a call logger
>> with some extras, I guess because that's my style of debugging. I'm
>> wondering if there's another angle on what you want to achieve.
>>
>> - Darko
>>
>>
>> On Fri, Mar 11, 2016 at 9:57 PM, Rodney M. Bates <rodney_bates at lcwb.coop
>> <mailto:rodney_bates at lcwb.coop>> wrote:
>>
>>     I have grown very disillusioned and discouraged about llvm.  It does
>>     not seem to have lived up to a couple of its claims that were very
>>     important to what I am trying to do.
>>
>>     The latest frustration is a recent discovery about its treatment of
>>     debug information and Dwarf.  They say its internal information is
>>     loosely based on Dwarf, and the anecdotal things I had looked at in
>>     the past suggested it was isomorphic to Dwarf, with different
>>     low-level data structure.  But I now find out, llvm only handles a
>>     very severe subset of Dwarf.
>>
>>     The decisive example is the subrange node.  Dwarf3 defines 18
>>     attributes for its DIE for a subrange type.  Llvm will only handle
>>     two, the lower and upper bounds.  Especially, it will not even handle
>>     a base type.  This will make a Modula-3 debugger completely useless
>>     for anything having subrange type.
>>
>>     I can't imagine what would have led to such a decision.  Is there any
>>     language that has subranges, but they all implicitly have the same
>>     base type?  It certainly won't support any language's subranges that I
>>     know of.  Llvm evidently doesn't have the commitment to multiple
>>     languages that Dwarf has.
>>
>>     My main motive for wanting an llvm back end for Modula-3 has always
>>     been a better Modula-3 debugger.  Dwarf is a vastly superior debug
>>     information format than the highly non-standard stabs we are now
>>     using.  I had imagined using llvm would be the way to get it.
>>
>>     At this point, it seems predictable that there is a lot more of
>>     Dwarf's very extensive multi-language support that we need, but that
>>     llvm will not pipe through, yet to be discovered.  There is no
>>     question that we would have to modify llvm to get any decent
>>     debugging, even parity with current m3cc/m3gdb.  I had believed we
>>     could avoid forking and modifying llvm, but apparently not so.
>>
>>     Which leads to my second disillusionment.  Llvm is constantly
>>     undergoing very rapid change, and if you need or want to track the
>>     changes, the claims about well-documented formats and interfaces are,
>>     well, at least exaggerated.
>>
>>     Recently, in the llvm mailing list, a couple of others who maintain
>>     things outside the official llvm tree have been seconding this, saying
>>     that important APIs constantly undergo extensive revisions, with no
>>     explanation other than just revised header files one must diff.  E.g.,
>>     no suggestions what removed/altered functions/parameters should be
>>     replaced by.  At least these posts give some confirmation that I am
>>     not just paranoid.
>>
>>     Even if we could avoid actual forking by persuading llvm to
>>     incorporate changes for us, we would then have to constantly track the
>>     development head to get them.  This in itself would entail so much
>>     time spent adapting, that I, for one, could hardly find time for any
>>     functional progress.
>>
>>     I have been through one round of updating bindings for DIBuilder, and
>>     that was a nightmare.  Whether looking at diffs in llvm headers and
>>     adapting our existing bindings, or starting over from scratch with the
>>     revised llvm headers, it is extremely tedious and error-prone.
>>     Moreover, since there is no intra-language type checking, many picky
>>     little errors will only show up as runtime assertion failures,
>>     segfaults, hard to explain behavior, etc.  And this all has to happen
>>     many times over before we could get a single debugger that would
>>     handle both languages, making diagnosis all the harder.
>>
>>     I have put a lot of work into this, and Peter obviously has put in a
>>     lot more.  But at this point, it looks to be far more productive to
>>     abandon llvm/Dwarf debugging and put the energy into improving m3gdb,
>>     using/further extending the existing stabs.
>>
>>     Or possibly modifying m3cc to produce Dwarf, but that raises a
>>     different issue.
>>
>>     --
>>     Rodney Bates
>>     rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>>     _______________________________________________
>>     M3devel mailing list
>>     M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>>     https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>>
>>
>>
> --
> Rodney Bates
> rodney.m.bates at acm.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160313/358a7c77/attachment-0002.html>