GNU bug report logs - #8621
build-aux/compile: avoid race condition failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8621 in the body.
You can then email your comments to 8621 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-automake <at> gnu.org
Subject: build-aux/compile: avoid race condition failure
Date: Thu, 05 May 2011 16:53:39 +0200

Is there any reason not to make the compile script
accommodate (in a race-free manner) situations like
the one described in http://debbugs.gnu.org/8616 ?

Message #8 received at 8621 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Jim Meyering <jim <at> meyering.net>
Cc: 8621 <at> debbugs.gnu.org
Subject: Re: bug#8621: build-aux/compile: avoid race condition failure
Date: Thu, 05 May 2011 21:06:48 +0200

Den 2011-05-05 16:53 skrev Jim Meyering:
> Is there any reason not to make the compile script
> accommodate (in a race-free manner) situations like
> the one described in http://debbugs.gnu.org/8616 ?

Yes, I can think of a couple.  When the compile script
is used to wrap MSVC (aka cl.exe), I think the generated
debug info will point to the actual source file, and if
the source file used to build the executable is gone when
it's time to debug it will be a less than stellar
experience. I imagine this problem to exist for other
toolchains as well? It's also currently not very easy to
override LN_S and MSVC does not understand the symlinks
generated by Cygwin, so symlinking is not a favorite (at
least not for the case where Cygwin is used to drive a
MSVC build).

That said, it's of course better to have any build at all,
even though the debugging experience is not 100% and
the LN_S override trouble can be fixed (and worked around
until it's fixed, IIRC).

I would prefer a solution that doesn't add more pain for
the MSVC case though.

Cheers,
Peter

Message #11 received at 8621 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Jim Meyering <jim <at> meyering.net>, 8621 <at> debbugs.gnu.org
Subject: Re: bug#8621: build-aux/compile: avoid race condition failure
Date: Thu, 05 May 2011 13:27:53 -0600

[Message part 1 (text/plain, inline)]

On 05/05/2011 01:06 PM, Peter Rosin wrote:
> Den 2011-05-05 16:53 skrev Jim Meyering:
>> Is there any reason not to make the compile script
>> accommodate (in a race-free manner) situations like
>> the one described in http://debbugs.gnu.org/8616 ?
> 
> Yes, I can think of a couple.  When the compile script
> is used to wrap MSVC (aka cl.exe), I think the generated
> debug info will point to the actual source file, and if
> the source file used to build the executable is gone when
> it's time to debug it will be a less than stellar
> experience. I imagine this problem to exist for other
> toolchains as well? It's also currently not very easy to
> override LN_S and MSVC does not understand the symlinks
> generated by Cygwin, so symlinking is not a favorite (at
> least not for the case where Cygwin is used to drive a
> MSVC build).

Is that true even in the face of #line directives?  That is, instead of
linking the file, could you create a temporary file that has appropriate
directives prepended to the content of the original file so that debug
information tracks back to the original file name but where the
compilation to -o is still independent of the original file?

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #14 received at 8621 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Eric Blake <eblake <at> redhat.com>
Cc: 8621 <at> debbugs.gnu.org
Subject: Re: bug#8621: build-aux/compile: avoid race condition failure
Date: Thu, 05 May 2011 23:09:35 +0200

Den 2011-05-05 21:27 skrev Eric Blake:
> On 05/05/2011 01:06 PM, Peter Rosin wrote:
>> Den 2011-05-05 16:53 skrev Jim Meyering:
>>> Is there any reason not to make the compile script
>>> accommodate (in a race-free manner) situations like
>>> the one described in http://debbugs.gnu.org/8616 ?
>>
>> Yes, I can think of a couple.  When the compile script
>> is used to wrap MSVC (aka cl.exe), I think the generated
>> debug info will point to the actual source file, and if
>> the source file used to build the executable is gone when
>> it's time to debug it will be a less than stellar
>> experience. I imagine this problem to exist for other
>> toolchains as well? It's also currently not very easy to
>> override LN_S and MSVC does not understand the symlinks
>> generated by Cygwin, so symlinking is not a favorite (at
>> least not for the case where Cygwin is used to drive a
>> MSVC build).
> 
> Is that true even in the face of #line directives?  That is, instead of
> linking the file, could you create a temporary file that has appropriate
> directives prepended to the content of the original file so that debug
> information tracks back to the original file name but where the
> compilation to -o is still independent of the original file?

I tested it and #line works.  I did this to test:

$ cat << EOF > foo.c
#include <windows.h>
int main(void)
{
        int i;
        for (i = 0; i < 1000; ++i)
                Sleep(120);
        return 0;
}
EOF
$ echo "#line 1 \"foo.c\"" > foo-random.c
$ cat foo.c >> foo-random.c
$ cl -MD -Zi -c foo-random.c
$ cl -MD -Zi -Fefoo.exe foo-random.obj
$ ./foo

I then attached the debugger to the running process and it gave me
foo.c and I could single step etc.  It keeps working even if I remove
foo-random.c.

So there is a path forward, but it seems a bit convoluted.  It would
perhaps be better if compile could be convinced to use the options
-Fe and -Fo as appropriate when it sees -o (for executables and
objects respectively) in the case of MSVC?

Cheers,
Peter

Message #17 received at 8621 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Eric Blake <eblake <at> redhat.com>, Jim Meyering <jim <at> meyering.net>,
	8621 <at> debbugs.gnu.org
Subject: Re: bug#8621: build-aux/compile: avoid race condition failure
Date: Wed, 11 Jan 2012 18:38:08 +0100

severity minor 8621
tags wontfix 8621
close 8621
thanks

Reference:
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8621>

Regarding this bug, Jim Meyering has wrote in a (off-list) reply:
>
> I'm not terribly concerned about that, since it impacts only the
> few people who are stuck using inferior compilers, and who insist
> on building in parallel, *and* for the few projects where the same
> source file ends up being compiled to two or more .o files.
>
> A very small user base.

And Peter Rosin has replied (again, off-list):
>
> For the MSVC case and a sufficiently new compile script (i.e. the one
> on master or branch-1.11, but not the one on maint), -Fe and -Fo are
> used as mentioned in the last post in the bug (#14), so MSVC is no
> longer affected and I hereby retract my concern.
>

I'm thus marking this bug as "wontfix", and closing it.  Hopefully, the
affected inferior compilers will die out anyway (the sooner the better).

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.