[M3devel] "C-generating backend progress report, that nobody asked for" :)

[Jay K]

  > Stock gdb won't ever parse M3 expressions nor print M3 values. 
 1) it comes close enough; I think; the languages aren't so different 
 2) you are maybe somewhat ignoring GUI debuggers, built off of gdb or otherwise; in that case, the textual expression of things matters less -- at least for input 
 > I would much prefer providing M3 library support for source debuggers to parse and print. 
On Windows the debuggers are extensible to varying degrees.cdb/ntsd/windbg you can write "pluings" for.Visual Studio you can plugin languages for clearly, as it already supports multiple. I don't know if the interfaces are public.

But I still expect...hypothetical still I realize.. we can come close enough, suchthat forking gdb won't be worth it. Extending other compilers, maybe.

 - Jay




Subject: Re: [M3devel] "C-generating backend progress report, that nobody asked for" :)
From: hosking at cs.purdue.edu
Date: Mon, 10 Sep 2012 20:07:27 -0400
CC: dragisha at m3w.org; m3devel at elegosoft.com
To: jay.krell at cornell.edu

Stock gdb won't ever parse M3 expressions nor print M3 values.So, there will always have to be some M3 support added.I would much prefer providing M3 library support for source debuggers to parse and print.I have no idea whether gdb has ever considered some of the extensibility support I pointed at in the link below.


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


On Sep 10, 2012, at 1:47 AM, Jay K <jay.krell at cornell.edu> wrote:Please, no.

Stock gdb and stock Visual C++ and stock cdb/ntsd/windbg ought to work well with Modula-3.
I expect they will pretty good pretty soon, and we should try to make them even better maybe...
by making globals visible in a reasonable fashion.


m3gdb isn't supported on Darwin and HP-UX (no stabs), at least.
If the gcc backend becomes obsolete and deleted...m3gdb would be the last of the
forked always-going-stale never-merging GPL stuff... i.e. another ripe target...



 - Jay

Subject: Re: [M3devel] "C-generating backend progress report, that nobody asked for" :)
From: hosking at cs.purdue.edu
Date: Sun, 9 Sep 2012 20:54:12 -0400
CC: dragisha at m3w.org; m3devel at elegosoft.com
To: jay.krell at cornell.edu

Stock debuggers are designed for C.  They generally will not be able to grok M3.  Better to use M3 run-time type information as per m3gdb.  See 10.1145/143103.143112.

On Sep 9, 2012, at 4:07 PM, Jay <jay.krell at cornell.edu> wrote:The current method stinks for stock debugging. As I understand, globals are combined into structs & the fields all have generated names, & global records are flattened therein.

It works. But stock debuggers see garbage.

 - Jay (briefly/pocket-sized-computer-aka-phone)
On Sep 9, 2012, at 12:22 PM, Antony Hosking <hosking at cs.purdue.edu> wrote:

I mis-spoke.  I think LLVM can cope with much the same as we currently have.  Front-end will continue to compute alignments and layouts.  We can assert the front-end's datalayout by passing it to LLVM explicitly, which will complain if it does not match the actual target.  This is a rather nice feature of LLVM in that it allows us to retain control while having LLVM optimize accordingly.
On Sep 9, 2012, at 11:05 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:Yes, agreed, these need to be properly typed too.First step will be to lift the M3CG interface.Problem: The compiler needs to control layout so that the run-time system knows where to find things.  This means that we need to assert alignments and layouts produced by the backend are the same as those in the front-end.  LLVM has nice ways to do this.  How will we do it in the C backend?  Does C have sufficient control over alignment?
On Sep 9, 2012, at 10:53 AM, Jay <jay.krell at cornell.edu> wrote:Btw, can this include "segment"/globals? Can they each be separate named variables? At least some of them?

 - Jay (briefly/pocket-sized-computer-aka-phone)
On Sep 9, 2012, at 7:48 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:

I'm looking at it...
First step is to lift slightly the level of M3CG to use properly typed memory access, instead of untyped address + offset.
On Sep 9, 2012, at 2:32 AM, Dragiša Durić <dragisha at m3w.org> wrote:I hope somebody will take on LLVM :).
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120911/cbefcacb/attachment-0002.html>