<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>Im starting to get nervous of so many things going on and Cm3 going anywhere.<br>We need to release something rather sooner than later.<br>Thanks in advance<br><br>--- El <b>vie, 29/3/13, Dirk Muysers <i><dmuysers@hotmail.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Dirk Muysers <dmuysers@hotmail.com><br>Asunto: Re: [M3devel] LLVM backend?<br>Para: m3devel@elegosoft.com, "Jay K" <jay.krell@cornell.edu><br>Fecha: viernes, 29 de marzo, 2013 11:58<br><br><div id="yiv1720140856">
<style><!--
#yiv1720140856 .yiv1720140856hmmessage P
{
margin:0px;padding:0px;}
#yiv1720140856 body.yiv1720140856hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style>
<div>
<div><font face="Arial">For me, the best debugger architecture still remains the
one</font></div>
<div><font face="Arial">designed by D.R.Hanson:</font></div>
<div><font face="Arial"></font> </div>
<div><font face="Arial"><a rel="nofollow" title="http://research.microsoft.com/pubs/69690/tr-99-04.pdf
CTRL + Click to follow link" target="_blank" href="http://research.microsoft.com/pubs/69690/tr-99-04.pdf">http://research.microsoft.com/pubs/69690/tr-99-04.pdf</a></font></div>
<div><font face="Arial"></font> </div>
<div><font face="Arial">platform-independent and easy to implement.</font></div>
<div style="font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal; -x-system-font: none;">
<div><br></div>
<div style="background: rgb(245, 245, 245) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;">
<div style=""><b>From:</b> <a rel="nofollow" title="mailto:jay.krell@cornell.edu
CTRL + Click to follow link" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">Jay K</a> </div>
<div><b>Sent:</b> Friday, March 29, 2013 5:09 PM</div>
<div><b>To:</b> <a rel="nofollow" title="mailto:rodney_bates@lcwb.coop
CTRL + Click to follow link" ymailto="mailto:rodney_bates@lcwb.coop" target="_blank" href="/mc/compose?to=rodney_bates@lcwb.coop">Rodney M. Bates</a> ; <a rel="nofollow" title="m3devel@elegosoft.com" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel</a>
</div>
<div><b>Subject:</b> Re: [M3devel] LLVM backend?</div></div></div>
<div><br></div>
<div dir="ltr">This doesn't completely make sense to me.<br>But it is kind of what
I expected and desire.<br><br><br>The debug format isn't the point.<br>parse.c
should have no knowledge of dwarf vs. stabs vs. coff vs. xcoff<br>vs. codeview
vs. vms vs. anything else.<br>It just happens that the authors found a private
channel in stabs.<br>Ideally any debug format used by any C compiler can fully
describe C,<br>and Modula-3.<br><br><br>The way it (any gcc frontend) is
supposed to work is you describe<br>the types using a compiler-internal form,
and that gets translated<br>into whatever the user requests that is
supported.<br>The primary limit as to what gcc can do is probably the object
file format.<br><br><br>Any backend without a private channel to the debugger,
i.e. the C backend<br>as well as an LLVM backend, will have degraded
debugging.<br><br><br>Perhaps a private channel can be found either way
though.<br>Like, gcc does have this "tfile" thing where after compilation,<br>a
separate tool goes over the .S file and makes changes.<br>Ideally we don't have
intermediate .S files though.<br><br><br>Now, on Windows, for
cdb/ntsd/windbg/kd, you can write debugger plugins.<br>.dlls loaded by the
debugger that have full access to symbols.<br>They are often very helpful, and
would surely help here.<br><br>I do wonder if it is worth changing TEXT for
debuggability.<br>Like, say, to always be flat, no trees, and always nul
terminated:<br>(actually I'd always write two zero bytes, in case of viewing the
ascii as unicode)<br><br><br>#define TEXT_FLAGS_UNICODE (0x00000001)<br>#define
TEXT_FLAGS_CONSTANT (0x00000002)<br><br><br>typedef struct
{<br> size_t flags;<br> size_t
length;<br> union
{<br> char*
ascii;<br> wchar_t*
unicode;<br> } data;<br>} *TEXT;<br><br> ? <br><br>If we
had merely that -- a more debugger/C-idiomatic representation<br>for TEXT, would
m3gdb's advantages decline significantly?<br><br><br>I'd also be open to just
plain typedef char* TEXT;<br>UTF8 encoded. Text.Length is slow, and Text.Concat
also slower.<br>But ideally we'd store the length. The length could also be
stored before the string.<br>On Windows, "BSTR"s work this way. i.e. it is
viable and practical and in wide use.<br>Also, MFC/ATL CStringW/CStringA do
this:<br>typedef struct {<br> wchar_t* data;<br>}
CStringW;<br><br><br>typedef struct {<br> char* data;<br>}
CStringA;<br><br>and then have an entire small struct before the data.<br>It
holdes, as I recall, at least the length and a reference count.<br>The strings
are reference counted and copy-on-write.<br>It is a nice implementation, but it
isn't quite relevant here, since<br>our TEXTs are immutable and garbage
collected.<br>The point is though, putting a struct in front of a char*/wchar_t*
is viable.<br>As long as the garbage collector doesn't get
confused.<br><br><br><br>Anyway, I think I'll start augmenting M3C.m3 to start
writing .ll files also.<br>We'll see how that goes. I realize it isn't the ideal
path.<br><br><br>Wrt nested variables/functions, I make a transform in the C
backend.<br>The LLVM backend will need to make a similar transform.<br>I think
the frontend should be willing/able to do this transform.<br>It would likely
help.<br><br><br> - Jay<br>
<div><font face="Arial"></font> </div></div></div></div></blockquote></td></tr></table>