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

Previous Next

Full log

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

Previous Next

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