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