On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote: > > > On 11/25/07 3:43 PM, Mark Mitchell wrote: > > >> My suggestion (not as a GCC SC member or GCC RM, but just as a fellow > >> GCC developer with an interest in improving the compiler in the same way > >> that you're trying to do) is that you stop writing code and start > >> writing a paper about what you're trying to do. > >> > >> Ignore the implementation. Describe the problem in detail. Narrow its > >> scope if necessary. Describe the success criteria in detail. Ideally, > >> the success criteria are mechanically checkable properties: i.e., given > >> a C program as input, and optimized code + debug information as output, > >> it should be possible to algorithmically prove whether the output is > >> correct. > > > Yes, please. I would very much like to see an abstract design > > document on what you are trying to accomplish. > > Other than the ones I've already posted, here's one: > > http://dwarfstd.org/Dwarf3Std.php > > Seriously. There is a standard for this stuff. My ultimate goal in > this project is that we comply with it Comply with it how?
There is no portion of the DWARF3 spec which requires you output information that is correct or useful. The same way the C standard does not require you to write correct programs, only valid ones, the DWARF3 spec does not require you to output correct information, only information that is encoded properly. It is certainly a goal of DWARF3 to allow producers to provide correct info (as witness by the one of the listed goals: "Debugging information must provide consumers a way to find the location of program variables, determine the bounds of dynamic arrays and strings, and possibly to find the base address of a subroutine's stack frame or the return address of a subroutine. Furthermore, to meet the needs of recent computer architectures and optimization techniques, debugging information must be able to describe the location of an object whose location changes over the object's lifetime.") If you search the entire spec for the word "correct", you will find it 3 times. If you search for "must", you will discover they all related to encoding or the goals of the standard. It may be entirely useless to output incorrect information, and in fact, worse than useless. It is however, compliant, as long as they are encoded properly. I have to say, this is typical of the argumentation you have used thus far in this thread, and honestly, it's not winning you any points. That said, nobody here believes we should output useless or incorrect info, even though we could. A lot of people appear to disagree with you about the best way to do it, and in fact, about what we should be trying to provide users in what cases. > >What part of instrusiveness are you concerned about? The change of >INSN_P such that it covers DEBUG_INSN_P too in the supported range? >Or the few changes that revert to the original INSN_P, in the few >exceptions in which DEBUG_INSN_P is not to be handled as an INSN? >I've heard this "intrusiveness" argument be pointed out so many times, >by so many people that claim to not have been able to keep up with the >thread, and who claim to have not looked at the patches at all, that >I'm more and more convinced it's just fear of the unknown than any >actual rational evaluation of the impact of the changes. Well, no. You yourself have shown it to be intrusiveness in the extreme, in the very next paragraphs! " At some point you have to face reality and see that such information isn't kept around by magic, it takes some effort, and this effort is needed at every location where there are changes that might affect debug information. And that's pretty much everywhere. " So, everywhere needs to change. That's pretty intrusiveness, no? "Sure, this might require a little bit more thinking in some optimizations. But in my experience fixing up the tree and rtl passes that needed tweaking, the additional thinking needed is a no-brainer in most cases; in a few, you have to work a bit harder to keep information around rather than simply noting it as unavailable. " Having to stop and think at every point in an optimization about the debug info, having to deal with debug info at every single point of change, and then your other patches This is intrusiveness as well (having to stop and think about debug info at every single point of every single optimization). You don't need to be this intrusiveness to stop outputting the incorrect info we do. >I've never seen this documented as such, and we've never worked toward > these stated goals. Who is we? I certainly have worked exactly towards these goals. As have almost all the authors of the current debugging info framework. The reason it is the way it is because these in fact, *were exactly the goals we were working towards*. As for not documented, a lot of gcc is not documented. If you look in the mailing list archives, you will even discover Diego is not the first one have exactly the viewpoint about what should and should not be debuggable, and that the community has consistenly worked towards exactly the viewpoint diego describes. Anyway, I give up on reading this thread. It has turned into a mess. You really need to step back and see that you have not achieved any sort of consensus of what levels of optimization should be how debuggable, before you start telling everyone their approach isn't as good as yours. I certainly wouldn't agree that we should take such intrusive steps to make -O2 -g as debuggable as you want, I'd much rather see us do what we can easily, and drop any info that ends up being incorrect.