<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></STYLE>
<META name=GENERATOR content="MSHTML 8.00.6001.19400"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody class=hmmessage leftMargin=0 topMargin=0
CanvasTabStop="true" name="Compose message area">
<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
title="http://research.microsoft.com/pubs/69690/tr-99-04.pdf
CTRL + Click to follow link"
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: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A
title="mailto:jay.krell@cornell.edu
CTRL + Click to follow link"
href="mailto: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
title="mailto:rodney_bates@lcwb.coop
CTRL + Click to follow link"
href="mailto:rodney_bates@lcwb.coop">Rodney M. Bates</A> ; <A
title=m3devel@elegosoft.com href="mailto: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></BODY></HTML>