[M3devel] LLVM backend?

[Rodney M. Bates]

On 03/28/2013 12:04 AM, Jay K wrote:
> I was thinking of looking into LLVM more. For selfish reasons -- resume growth, but no matter.
>
> 1) Tony, are you making progress? Should I wait? Collaberate? Go it alone?

(Jay, I reversed the order of your paragraphs here, because my responses make more sense in that order.)

 > Actually I was just skimming "parse.c"..I don't remember exactly how I decided it is all a stabs-specific hack.
 > Though, I do realize 1) typeids are encoded in identifier names, which certainly hurts debugging
 > w/o m3gdb 2) types aren't being described as they ought to be.
 >

Yes, it is very much a hack.  For one thing, stabs itself is something of a hack.  For another,
a lot of the fields of stabs info are really treated as just containers for some extremely
Modula-3-specific info, that, to be fair, isn't provided for in any reasonable way by
true stabs.  Meanwhile, some true stabs stuff is produced too, but not used in m3gdb, because
it isn't quite right or helpful.  parse.c and m3gdb are highly coupled by all this.  Stock gdb's
code to read stabs is augmented by tons of stuff to further decode the M3-specific info
inserted by parse.c, and tons more to interpret it.

Moreover, debug info and code to be translated effectively become diverging streams in
parse.c, notwithstanding the fact that they are often interspersed.  This makes it very
difficult for debug info to reflect anything gcc does to the code.  I believe the stabs
info is mostly or entirely untouched after parse.c, though I haven't ever thoroughly
vetted this.

One specific place where this particularly hurts right now is with nonlocal references,
static links, etc.  With the advent of tree-nested.c, in later gcc versions, the runtime
storage model is drastically reworked in gcc, after the stabs has already been produced.
That seriously broke a lot of stuff I had working in m3gdb.  I have dabbled with Mickey-
Mouse schemes to emit purely additional stabs info in tree-nested.c, without changing what
was already there, then have m3gdb use it to selectively override the earlier-produced
stabs.  I never finished this, and have only limited confidence it is even feasible.

> 2) An LLVM backend would I suspect have the same lack of m3gdb support as a C backend.
> Does that bother people?

LLVM has a lot of already provided support for dwarf debug info, keeping it together with code,
and helping to transform it in parallel with code, when optimizations, etc., are done.
Meanwhile, dwarf itself is vastly more complete and appears to me, from superficial study,
to be capable of representing all, or certainly most, of what is needed for good Modula-3 debugging.
For these two reasons, I think LLVM plus dwarf present by far the best method to support
a nice language-specific debugging experience, while leaving massive kludges behind.

This is one big reason why I support an LLVM back end.  It would indeed require significant
work to get debug support.  But it would be so much easier and far more pleasant than
the alternatives.  That includes even the alternative of further fixing the existing m3gdb/gcc,
which still needs perhaps as much additional work as has already gone into it.  I am
attached to it only because it now provides a lot more function than anything else
we have (and which I use a lot).  Mucking around in M3ified stabs is, for me, strictly a
destination, not a journey.

So, the short answer is, it bothers me less than any other option.