<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'>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><br><br><br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Thu, 28 Mar 2013 10:23:17 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] LLVM backend?<br>> <br>> <br>> <br>> On 03/28/2013 12:04 AM, Jay K wrote:<br>> > I was thinking of looking into LLVM more. For selfish reasons -- resume growth, but no matter.<br>> ><br>> > 1) Tony, are you making progress? Should I wait? Collaberate? Go it alone?<br>> <br>> (Jay, I reversed the order of your paragraphs here, because my responses make more sense in that order.)<br>> <br>> > Actually I was just skimming "parse.c"..I don't remember exactly how I decided it is all a stabs-specific hack.<br>> > Though, I do realize 1) typeids are encoded in identifier names, which certainly hurts debugging<br>> > w/o m3gdb 2) types aren't being described as they ought to be.<br>> ><br>> <br>> Yes, it is very much a hack. For one thing, stabs itself is something of a hack. For another,<br>> a lot of the fields of stabs info are really treated as just containers for some extremely<br>> Modula-3-specific info, that, to be fair, isn't provided for in any reasonable way by<br>> true stabs. Meanwhile, some true stabs stuff is produced too, but not used in m3gdb, because<br>> it isn't quite right or helpful. parse.c and m3gdb are highly coupled by all this. Stock gdb's<br>> code to read stabs is augmented by tons of stuff to further decode the M3-specific info<br>> inserted by parse.c, and tons more to interpret it.<br>> <br>> Moreover, debug info and code to be translated effectively become diverging streams in<br>> parse.c, notwithstanding the fact that they are often interspersed. This makes it very<br>> difficult for debug info to reflect anything gcc does to the code. I believe the stabs<br>> info is mostly or entirely untouched after parse.c, though I haven't ever thoroughly<br>> vetted this.<br>> <br>> One specific place where this particularly hurts right now is with nonlocal references,<br>> static links, etc. With the advent of tree-nested.c, in later gcc versions, the runtime<br>> storage model is drastically reworked in gcc, after the stabs has already been produced.<br>> That seriously broke a lot of stuff I had working in m3gdb. I have dabbled with Mickey-<br>> Mouse schemes to emit purely additional stabs info in tree-nested.c, without changing what<br>> was already there, then have m3gdb use it to selectively override the earlier-produced<br>> stabs. I never finished this, and have only limited confidence it is even feasible.<br>> <br>> > 2) An LLVM backend would I suspect have the same lack of m3gdb support as a C backend.<br>> > Does that bother people?<br>> <br>> LLVM has a lot of already provided support for dwarf debug info, keeping it together with code,<br>> and helping to transform it in parallel with code, when optimizations, etc., are done.<br>> Meanwhile, dwarf itself is vastly more complete and appears to me, from superficial study,<br>> to be capable of representing all, or certainly most, of what is needed for good Modula-3 debugging.<br>> For these two reasons, I think LLVM plus dwarf present by far the best method to support<br>> a nice language-specific debugging experience, while leaving massive kludges behind.<br>> <br>> This is one big reason why I support an LLVM back end. It would indeed require significant<br>> work to get debug support. But it would be so much easier and far more pleasant than<br>> the alternatives. That includes even the alternative of further fixing the existing m3gdb/gcc,<br>> which still needs perhaps as much additional work as has already gone into it. I am<br>> attached to it only because it now provides a lot more function than anything else<br>> we have (and which I use a lot). Mucking around in M3ified stabs is, for me, strictly a<br>> destination, not a journey.<br>> <br>> So, the short answer is, it bothers me less than any other option.<br>> <br>> <br>> <br>> <br></div> </div></body>
</html>