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: Ada files now checked in


> Date: Tue, 2 Oct 01 21:50:05 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: mrs@windriver.com
> Cc: gcc@gcc.gnu.org

>     This breaks (can break) multi builds when one source tree is used by
>     two or more build systems.

> No, because, like c-parse.c, the contents of the files are a function only
> of sources and not of the target, host, or build machine.

This means that you have never seen a build fail.  I am sorry you
haven't had the opportunity.  For example (from memory), when a
Windows build generates a cp/parse.c file on Windows using Windows
linefeed conventions and that file winds up in the source tree, and
the UNIX build then sees the file is up to date, and doesn't rebuild
it, and uses that file, and fails because of the linefeed convention
the builds have in the past, broken.  Only a clean enough rebuild
fixes it.  Luckily, the Windows compiler doesn't get distressed at the
UNIX linefeed convention, so as long as the UNIX builds goes faster
than the Windows build, or runs before it, the builds work.

Now, you can tell me the problem has been since been fixed, but it
sounds more like you wanted to tell me the problem didn't exist.  That
is futile.

Further, I expected you to see the obvious race condition in even
generating the file, even if they are otherwise identical.  In one
build, you write cp/parse.c (and if not that file, at least one of the
other files), in the other build, you open it, truncate it, write half
of it, and then back in the first build, you read and compile that
file, viola, you die.

You can tell me it doesn't exist, but this too is futile, it did
exist.  I have no reason to believe that the problem has been fixed.
I'm sure these sorts of race conditions exist still.  A quick audit
shows that the cp/parse.[ch] race problems seem to be virtually
eliminated, this is good.  But, if you look closely, and actually
audit for a race condition, you will see that even now, as good as the
Makefile is, there is still a race condition present.  It can be
eliminated with just a little bit more work.  To me, the race
condition is obvious.

To work, you have to ensure that the generation of the files cannot
differ between all possible builds, or that should it differ, that
those differences are not material, and that the generation has no
race conditions.

We cannot hope to make the software better, if we cannot understand
its shortcomings.


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