This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC


Alexandre Oliva <aoliva@redhat.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]