<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>m3gdb:</div><div> is GPL</div><div> is a fork, that will never be merged </div><div> that isn't being updated </div><div> is big </div><div> that doesn't support some platforms e.g. Darwin, HP-UX </div><div> </div><div><br></div><div>cm3cg has some but not all of those characteristics</div><div><br></div><div><br></div><div>Meanwhile, debugging on NT and Darwin is limited to line numbers</div><div>and integers and floats. No useful view of structs or globals</div><div>is available.</div><div> </div><div> </div><div>And as I understand..can anyone agree/disagree?.. gets its</div><div>data from the backend via a total backdoor hack, that is very difficult</div><div>to duplicate. E.g. including with llvm, including if we generated</div><div>typeful gcc trees like any normal backend would do.</div><div>I speculate, maybe it will be possible to output some assembly</div><div>files on the side with just the stabs directives.</div><div><br></div><div><br></div><div><br></div><div>I'm hoping that:</div><div> gdb on Darwin will improve drastically via the C backend; it hasn't yet </div><div> windbg and Visual Studio ditto </div><div><br></div><div> </div><div>gdb on platforms that support m3gdb will come close to m3gdb,</div><div>but parity might not be achievable.</div><div><br></div><div><br></div><div>Our target support continues to lag. </div><div> DragonflyBSD? </div><div> OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) </div><div> ARM_NT? </div><div> {PPC,MIPS,ARM,SH,I386}_CE? </div><div> ARM_DARWIN? Was mostly there already. </div><div> PPC32_XBOX? </div><div> AMD64_NT? This should come along fairly soon now via the C backend. </div><div><br></div><div><br></div><div>Let's see how good we can get stock debuggers working with our C. Ok?</div><div><br></div><div><br></div><div> - Jay </div><br><br><div><div id="SkyDrivePlaceholder"></div>> From: rcolebur@SCIRES.COM<br>> To: m3devel@elegosoft.com<br>> Date: Wed, 6 Feb 2013 23:13:37 +0000<br>> Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI<br>> <br>> I concur with Rodney, we must preserve the m3gdb capability and the backends that support it!<br>> --Randy Coleburn<br>> <br>> -----Original Message-----<br>> From: Rodney M. Bates [mailto:rodney_bates@lcwb.coop] <br>> Sent: Wednesday, February 06, 2013 12:25 PM<br>> To: m3devel@elegosoft.com<br>> Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI<br>> <br>> <br>> <br>> On 02/05/2013 02:28 AM, Jay K wrote:<br>> > I will fix it, but I do desire to drop the old backend entirely.<br>> > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded.<br>> > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms.<br>> ><br>> <br>> <br>> I am not sure what is happening here, but it is making me very nervous with talk of removing backends.<br>> <br>> I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger.<br>> <br>> Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc.<br>> <br>> A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its<br>> Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now.<br>> <br>> And I use m3gdb all the time in my own work.<br>> <br>> Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions.<br>> <br>> <br>> ><br>> > - Jay<br>> ><br></div> </div></body>
</html>