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

Reid Kleckner rnk at google.com
Mon Mar 31 20:18:23 PDT 2014


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].


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140331/4197e812/attachment.html>


More information about the cfe-commits mailing list