[PATCH][Driver] Teach the clang driver how to correctly parse response files on Windows.

Andrea Di Biagio andrea.dibiagio at gmail.com
Tue Apr 8 09:09:28 PDT 2014


Hi Reid,

thanks for the very useful feedback and sorry for the late reply...

On Tue, Apr 1, 2014 at 4:18 AM, Reid Kleckner <rnk at google.com> wrote:
> Whoops, missed this over vacation.  My intention was to conditionalize this
> on the driver mode, i.e. clang-cl or gcc-style, but that computation happens
> further down, so I never got to this.
>
> The big question is, which syntax does mingw gcc understand?  If it's the
> libiberty style escaping, then the ifdef won't work, since clang could be
> either mingw gcc or MSVC's cl depending on argv[0].

So, I just tried mingw (mingw32-gcc - gcc version 4.8.1) on a windows host.
Unfortunately,  when expanding response files, mingw seems to
understand a different syntax than MSVC's cl.

Example 1:

//----- test.c --
int a;
//-----

//-- response.txt --
-I.\
//-----

c:\> mingw32-gcc.exe -v @response.txt test.c

produces the following verbose output:
COLLECT_GCC_OPTIONS='-v' '-I' '. '

Example 2:

//-- response.txt --
-I.\ -I.\
//-----

I get the following output:
COLLECT_GCC_OPTIONS='-v' '-I' '. -I.'

Example 3:

//-- response.txt --
-I.\ test.c
//-----

c:\> mingw32-gcc.exe @response.txt
mingw32-g++.exe: fatal error: no input files
compilation terminated.

Instead, MSVC correctly compiles this last example.

In conclusion, my solution based on the ifdef LLVM_ON_WIN32 would only
be compliant with what MSVC's cl does; it would not work if we want to
be compliant with mingw.

-Andrea


>
>
> On Mon, Mar 31, 2014 at 6:54 PM, Andrea Di Biagio
> <andrea.dibiagio at gmail.com> wrote:
>>
>> ping.
>>
>> Any feedback would be appreciated.
>> Thanks!
>>
>> On Thu, Mar 20, 2014 at 3:04 PM, Andrea Di Biagio
>> <andrea.dibiagio at gmail.com> wrote:
>> > ping.
>> >
>> > On Fri, Mar 14, 2014 at 11:14 AM, Andrea Di Biagio
>> > <andrea.dibiagio at gmail.com> wrote:
>> >> Hi,
>> >>
>> >> This patch teaches the driver how to use function
>> >> 'llvm::cl::TokenizeWindowsCommandLine' to correctly parse response
>> >> files on Windows.
>> >>
>> >> Microsoft defines specific rules for parsing c/c++ command-line
>> >> arguments here: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
>> >> .
>> >> Those rules are currently implemented by function
>> >> TokenizeWindowsCommandLine in llvm "lib/Support/CommandLine.cpp".
>> >>
>> >> However, the clang driver doesn't call that method when the host is
>> >> WIN32. Instead, we always call function
>> >> llvm::cl::TokenizeGNUCommandLine.
>> >>
>> >> This is problematic, for example, when we have backslashes in a
>> >> response file (see test backslash-in-response-file.c in the patch).
>> >>
>> >> This patch also adds XFAIL win32 to the driver test Driver/at_file.c.
>> >> That test verifies that the driver correctly expands arguments
>> >> surrounded by single quotes. On Windows, that test would start failing
>> >> because, single quotation marks cannot be used to identify single
>> >> arguments.
>> >>
>> >> The fix for Driver/at_file.c is probably not ideal. Adding XFAIL win32
>> >> means that the test would be an expected failure if the target triple
>> >> contains 'win32'. This is ok in general if both host and target are
>> >> the same (i.e. we are not testing a cross-compiler). This is a problem
>> >> however for cross compilers where the host is win32 but the target is
>> >> not  win32.
>> >>
>> >> At the moment there is no way to tell lit that the test should fail
>> >> based on the information of the host platform (and not only on the
>> >> target triple). I have an idea about how to improve LIT and
>> >> consequently test Driver/at_file.c. If ok, I plan to send another
>> >> patch for improving it.
>> >>
>> >> Please let me know if this patch is ok to submit.
>> >>
>> >> Thanks in advance,
>> >>
>> >> Andrea Di Biagio
>> >> SN Systems - Sony Computer Entertainment Group
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>



More information about the cfe-commits mailing list