On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote: > >> systems and generates reasonable code. Unfortunately, and sorry PCC > >> (stabs, really?), > > > > Feel free to add dwarf, the source is out there, and it wouldn't be > > especially difficult to do it. I just haven't had time. > > Stabs was "for free" :-) > > I'm not so sure (a year back I looked at the code with that in mind), > and wonder if any quick hack would end up being opportunity lost.
I have not looked at it, nor have I looked at pcc at all in a long time, so what I'm missing may just be otherwise obvious context, but: > PCC, as a "classic" C compiler, only generates debug information at > -O0. This this is because the stabs code is restricted to the > un-optimized code generator path. Having the backend restricted to > DWARF when '-O0' might just be ok, were it not for SSA (static single > assignment). > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > forces issues like: [...] I'm missing something; SSA is just a style of program representation. Are you talking about a hypothetical future where pcc's backend grows an (additional, or replacement) SSA-based layer? Or is pcc's optimizing backend already SSA-based (per above, I don't know one way or the other) and you're talking about making that preserve debug info? Either way, it seems like adding DWARF support to the non-optimizing backend is an orthogonal issue. Unless, I guess, what you're talking about is throwing away the existing backend entirely and writing a new SSA-based one, in which case I'd gently suggest that this is a large project :-) > (I've got to admit that I wonder if C is the best language for an > optimizing compiler; but then, it is what we have) It is not, but one can do a lot worse. Plus if you try you end up in bootstrap hell like e.g. lang/ghc. -- David A. Holland [email protected]
