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]

Re: egcs-1998-06-12: bootstrap failure


>>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:
>
> Craig> Oh, wow, you're right, that *should* be fixed; the current
> Craig> message is highly misleading!  You seem to be the only person
> Craig> who understood this (that I know of anyway)!
>
>Isn't it only potentially confusing when bootstrapping the compiler?
>Even then compilation-mode took me to the right place last time I got
>one.  I don't remember being confused as a user of other compilers
>doing this, though this may have been while compiling Fortran rather
>than C.

Yes, well, it certainly would help that the message would look
much more distinct in most any other context.  But not always:
these diagnostics will necessarily include dead pathnames that
might "curiously" match live ones in a user's system.  (E.g. the
compiler is built on one system, binaries are distributed to
another that uses similar pathnames for completely different stuff,
and then crashes with a diagnostic that looks rather confusing.)
Mixing live and dead pathnames in reports is unwise.  (A "live"
pathname, in this context, is one that is being used as part of
the live activity, e.g. /home/user/gnu/gcc/expr.c in "gcc expr.c",
which might have nothing to do with gcc itself.  A "dead" pathname
is one that is not actually being used, but was recorded during a
distinct operation, e.g. /home/user/gnu/gcc/expr.c in "make bootstrap",
where `gnu' happens to be the name *that* user gave his egcs
source directory.  But the same "gcc expr.c" the *other* user typed
could report the latter, identical, pathname if he manages to crash
the compiler while compiling his own, unrelated-to-gcc expr.c module.)

Just seems to me this problem *already* confused several people and
wasted time.  Why not fix it so that no longer happens?  And, does
it really make for sound user-interface design that the Emacs
compilation mode's next-error function is given *two* streams of
indistinguishable info to call up for the user -- one being the
stream of pointers to bugs (e.g. where the compiler detects errors)
in the user's own code, and the other the stream of pointers to where
any code the user happened to be running crashed in the source code
(said source code being possibly inaccessible, or wrong, due to the
pathname(s) being "dead")?

I think this is a good example of a "feature" that takes clever
advantage of existing tools and practices; makes hacking code
more "fun"; and is wrong-headed.  IMO the "GNU architecture" for
automatically parsed stderr format was not, or should not have been,
designed to include pointers to where system code crashes in a
non-distinguishable way.  (I have no problem with making these
pointers distinguishable as an architectural feature; e.g. a clear
syntactic marker saying "this pointer is to an internal bug",
combined with improving next-error so it knows whether to follow
such a pointer based on whether the user has flagged himself as
an internals hacker for some or all products.  In fact, my ideal
totally-in-my-head all-source-all-the-time operating environment
has long included such a distinction.)

Maybe this should be taken up on the pertinent GNU-toolset list,
though; can't recall offhand what the name of that might be, but
I do think there is such a thing.

        tq vm, (burley)


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