Commit Graph

15 Commits

Author SHA1 Message Date
Bruno Cardoso Lopes 1c10872150 [CrashReproducer] Provide a clean dir path for -fmodules-cache-path
The most common workflow with module reproducers involves deleting the
module cache before running the script. This happens because leftovers
from the crash are present in the cache and could trigger unrelated and
confusing errors, misleading from the initial reproduction intent.
Change this to point to a clean path but leave the leftovers untouched.

rdar://problem/28655070

llvm-svn: 289176
2016-12-09 03:11:48 +00:00
Bruno Cardoso Lopes 0df3e04460 [CrashReproducer] Always use realpath for destination
When running reproducer scripts we need that original symlinks from the
source filesystem are reproduced in the VFS so that different virtual
paths can map to the same file, allowing the FileManager to share the
same UID between these virtual entries. This avoids all sorts of module
redefinition errors when using frameworks.

llvm-svn: 268825
2016-05-06 23:58:58 +00:00
Bruno Cardoso Lopes fc8644cd62 [CrashReproducer] Setup 'use-external-names' in YAML files.
Hide the real paths when rebuilding from VFS by setting up the crash
reproducer to use 'use-external-names' = false. This way we avoid
module redifinition errors and consistently use the same paths against
all modules.

With this change on Darwin we are able to simulate a crash for a simple
application using "Foundation/Foundation.h" (which relies on a bunch of
different frameworks and headers) and successfully rebuild all the
modules by relying solely at the VFS overlay.

llvm-svn: 266234
2016-04-13 19:28:21 +00:00
Bruno Cardoso Lopes f854b042e7 [CrashReproducer] Add -fmodule-cache-path to reproducer script
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.

llvm-svn: 265162
2016-04-01 17:39:08 +00:00
Bruno Cardoso Lopes d878e28e67 Reapply [2] [VFS] Add 'overlay-relative' field to YAML files
This reapplies r261552 and r263748. Fixed testcase to reapply.

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
    {
      "type": "file",
      "name": "stdio.h",
      "external-contents": "/usr/include/stdio.h"
    },
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

llvm-svn: 263893
2016-03-20 02:08:48 +00:00
Bruno Cardoso Lopes 9e2f9d818f Revert "Reapply [VFS] Add 'overlay-relative' field to YAML files"
Tests failing on
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/46102

This reverts commit a1683cd6c9e07359c09f86e98a4db6b4e1bc51fc.

llvm-svn: 263750
2016-03-17 21:30:55 +00:00
Bruno Cardoso Lopes 016b2d0ddc Reapply [VFS] Add 'overlay-relative' field to YAML files
This reapplies r261552.

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
    {
      "type": "file",
      "name": "stdio.h",
      "external-contents": "/usr/include/stdio.h"
    },
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

llvm-svn: 263748
2016-03-17 21:11:23 +00:00
Benjamin Kramer f8bff1c31c Use a simpler set of mock headers for the vfs+modules crash recovery tests.
The System/ mock is large and too complex for this test. It can cause
the tests to fail in mysterious ways as it depends on the resource dir
being present, which is not really supported for driver tests (using
%clang instead of %clang_cc1). Copy the tree and trim out all the
%unnecessary fat.

llvm-svn: 263718
2016-03-17 16:19:51 +00:00
Bruno Cardoso Lopes b76c027717 Reapply [2]: [VFS] Add support for handling path traversals
This was applied twice r261551 and 263617 and later reverted because:

(1) Windows bot failing on unittests. Change the current behavior to do
not handle path traversals on windows.

(2) Windows bot failed to include llvm/Config/config.h in order to use
HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp.

Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.

Include the support for symlinks into components. Given the path:

/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.

Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.

Differential Revision: http://reviews.llvm.org/D17104

rdar://problem/24499339

llvm-svn: 263686
2016-03-17 02:20:43 +00:00
NAKAMURA Takumi 9ed443ccca Revert r263617, "Reapply: [VFS] Add support for handling path traversals"
It broke standalone clang build.

llvm-svn: 263636
2016-03-16 12:15:29 +00:00
Bruno Cardoso Lopes c9daaaedb6 Reapply: [VFS] Add support for handling path traversals
This is originally r261551, reverted because of windows bots failing on
unittests. Change the current behavior to do not handle path traversals
on windows.

Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.

Include the support for symlinks into components. Given the path:

/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.

Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.

Differential Revision: http://reviews.llvm.org/D17104

rdar://problem/24499339

llvm-svn: 263617
2016-03-16 04:39:38 +00:00
Bruno Cardoso Lopes be056b1667 Revert "[VFS] Add support for handling path traversals"
This reverts commit r261551 due to failing tests in windows bots:

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10054

Failing Tests (4):
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName

llvm-svn: 261654
2016-02-23 17:06:50 +00:00
Bruno Cardoso Lopes b7eb8db023 Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix call to getVFSFromYAML in unittests"
This reverts commit r261552 and r261556 because of failing unittests on
windows:

Failing Tests (4):
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
    Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName

llvm-svn: 261613
2016-02-23 07:06:12 +00:00
Bruno Cardoso Lopes 8c03c54200 [VFS] Add 'overlay-relative' field to YAML files
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
    {
      "type": "file",
      "name": "stdio.h",
      "external-contents": "/usr/include/stdio.h"
    },
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

llvm-svn: 261552
2016-02-22 18:41:09 +00:00
Bruno Cardoso Lopes 956e6a0dc6 [VFS] Add support for handling path traversals
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.

Include the support for symlinks into components. Given the path:

/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.

Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.

Differential Revision: http://reviews.llvm.org/D17104

rdar://problem/24499339

llvm-svn: 261551
2016-02-22 18:41:01 +00:00