[M3devel] Compiler upgrade broken in Hudson CI

[Jay K]

m3gdb: is GPL is a fork, that will never be merged  that isn't being updated  is big  that doesn't support some platforms e.g. Darwin, HP-UX  
cm3cg has some but not all of those characteristics

Meanwhile, debugging on NT and Darwin is limited to line numbersand integers and floats. No useful view of structs or globalsis available.  And as I understand..can anyone agree/disagree?.. gets itsdata from the backend via a total backdoor hack, that is very difficultto duplicate. E.g. including with llvm, including if we generatedtypeful gcc trees like any normal backend would do.I speculate, maybe it will be possible to output some assemblyfiles on the side with just the stabs directives.


I'm hoping that: gdb on Darwin will improve drastically via the C backend; it hasn't yet  windbg and Visual Studio ditto 
 gdb on platforms that support m3gdb will come close to m3gdb,but parity might not be achievable.

Our target support continues to lag.  DragonflyBSD?  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)  ARM_NT?  {PPC,MIPS,ARM,SH,I386}_CE?  ARM_DARWIN? Was mostly there already.  PPC32_XBOX?  AMD64_NT? This should come along fairly soon now via the C backend. 

Let's see how good we can get stock debuggers working with our C. Ok?

 - Jay 

> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Wed, 6 Feb 2013 23:13:37 +0000
> Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI
> 
> I concur with Rodney, we must preserve the m3gdb capability and the backends that support it!
> --Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Wednesday, February 06, 2013 12:25 PM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI
> 
> 
> 
> On 02/05/2013 02:28 AM, Jay K wrote:
> > I will fix it, but I do desire to drop the old backend entirely.
> > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded.
> > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms.
> >
> 
> 
> I am not sure what is happening here, but it is making me very nervous with talk of removing backends.
> 
> 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.
> 
> 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.
> 
> 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
> 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.
> 
> And I use m3gdb all the time in my own work.
> 
> 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.
> 
> 
> >
> >   - Jay
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130207/11baab73/attachment-0002.html>