Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Alexandre, I have to say that in my opinion absurd arguments like this > > do not strengthen your position. > > I'm sorry that you feel that way, but I don't understand why you and > so many others apply different compliance standards to debug > information. Why do you regard compiler output that causes systems to > fail because they process incorrect debug information as any more > acceptable than compiler output that causes system to fail because > they process incorrect instructions?
Because a compiler that generates incorrect instructions is completely useless for all users. A compiler that generates incorrect debug information, or no debug information at all, or debug information which is randomly correct and incorrect, is still quite useful for many users. Evidence: gcc today. I have to say that I find your arguments along these lines to be so absurd as to be nearly incomprehensible. gcc does not exist to adhere to standards. It exists to provide a service to its users. I and so many others apply different compliance standards to debug information because that is appropriate for our user base. > Do you just not see how serious the problem is, or just not care about > the growing number of tools and people who need the information to be > standard-compliant? Do you just not see that your false dichotomies have nothing to do with the real usage of gcc in the real world? Is anybody out there saying that we should absolutely not improve the debug information? No, of course not. All serious people are in favor of improving the debug information. We are just saying that for debug information it is appropriate to weigh different user needs. Those needs include compilation time and size of generated files. This is not true for correctness of generated code. There is no such weighing in that area; the generated code must be correct or the compiler is completely useless. > > What we sacrifice in these cases is the ability to sometimes get a > > correct view of at most two or three local variables being modified in > > the exact statement being executed at the time of the signal. > > Aren't you forgetting that complex statements and scheduling can make > it much worse than this? In fact, that there can be very many "active > statements" at any single point in the code (and this is even more > critical on some architectures such as IA64), and that, in these > cases, your suggested notion of "line notes" is pretty much > meaningless, for they will be present between pretty much every pair > of statements anyway? Fortunately not every single instruction is going to change a user visible variable. But, yes, that is a potential issue. We will have to see what the effect is on debug information size. > > Moreover, a tool which reads the debug information can determine that > > it is looking at instructions in the middle of the statement, and that > > therefore the known locations of local variables need not be correct. > > So in fact we don't even lose the ability to get a correct view. What > > we lose is the ability to in some cases see a value which actually is > > available, but which the debugging tool can not prove to be available. > > Feel like proposing this "relaxed mode" to the DWARF standardization > committee? At least an annotation that tells debug info consumers not > to trust fully the information encoded there, because it's only valid > at instructions marked with the "is_stmt" flag, or some such. No, my personal interest in standardization of debugging information is near-zero. > Why do you want -g to generate incorrect debug information, and force > debug information consumers that have use cases different than yours, > and distributors of such debug information, to decide between changing > their build procedures to get what the compiler should have long given > them, or living with unreliable information? I guess it must be because I'm an extremist who can only cares about one thing, and I have no interest in considering issues that other people might care about. What other possible explanation could there be? > Just so that you, who don't care so much about the correctness of this > information yet, can shave off some bytes from your object files? Why > shouldn't you use an option such as -gimme-just-what-I-need-no-more or > -fsck-up-my-debug-info-I-dont-care-about-standards instead? First, we add the option. Second, we see what the results look like. Third, we decide what the default should be. Like it or not, the large size of debug information is a serious issue for many people. Ian
