summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
* [AARch64] Add Marvell ThunderX3T110 supportWei Zhao2020-06-171-1/+8
| | | | | | | | | | | This is the first checkin to support Marvell ThunderX3T110. Initial definition of the micro-ops of the instructions in ThunderX3T110 is included. Differential Revision: https://reviews.llvm.org/D78129 (cherry picked from commit 382d3a85e2a9269569e7fb8caa487d7ef57900c6)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-031-1/+1
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* Make llvm::crc32() work also for input sizes larger than 32 bits.Hans Wennborg2020-02-061-0/+20
| | | | | | | | | | | | The problem was noticed by the Chrome OS toolchain folks (crbug.com/1048445) because llvm-objcopy --add-gnu-debuglink would insert the wrong checksum when processing a binary larger than 4 GB. That use case regressed in 1e1e3ba2526 when we started using llvm::crc32() in more places. Differential revision: https://reviews.llvm.org/D74039 (cherry picked from commit 6c4a8bc0a9f6a466d90d542bef66d69550c1b041)
* [Support] Fix race in threading test, found by TSanSam McCall2020-01-271-1/+3
| | | | (cherry picked from commit 18e6a65bae93a7bf0e718415b394fe4b0f09221e)
* [DebugInfo][Support] Replace DWARFDataExtractor size functionJames Henderson2020-01-131-0/+9
| | | | | | | | | | | | | | | | This patch adds a new size function to the base DataExtractor class, which removes the need for the DWARFDataExtractor size function. It is unclear why DWARFDataExtractor's size function returned zero in some circumstances (i.e. when it is constructed without a section, and with a different data source instead), so that behaviour has changed. The old behaviour could cause an assertion in the debug line parser, as the size did not reflect the actual data available, and could be lower than the current offset being parsed. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D72337
* [Support] Optionally call signal handlers when a function wrapped by the the ↵Alexandre Ganea2020-01-111-0/+30
| | | | | | | | | CrashRecoveryContext fails This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default. This is a support patch for D69825. Differential Revision: https://reviews.llvm.org/D70568
* [Support][NFC] Add an explicit unit test for Process::getPageSize()Bruno Ricci2020-01-091-0/+38
| | | | | It turns out that it was only tested indirectly. For now test only on Linux X86-64 and aarch64.
* AArch64: add missing Apple CPU names and use them by default.Tim Northover2020-01-081-1/+46
| | | | | | | | Apple's CPUs are called A7-A13 in official communication, occasionally with weird suffixes which we probably don't need to care about. This adds each one and describes its features. It also switches the default CPU to the canonical name for Cyclone, but leaves legacy support in so that existing bitcode still compiles.
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-071-2/+2
| | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
* [FileCheck] Remove FileCheck prefix in APIThomas Preud'homme2020-01-061-73/+71
| | | | | | | | | | | | | | | | | | Summary: When FileCheck was made a library, types in the public API were renamed to add a FileCheck prefix, such as Pattern to FileCheckPattern. Many types were moved into a private interface and thus don't need this prefix anymore. This commit removes those unneeded prefixes. Reviewers: jhenderson, jdenny, probinson, grimar, arichardson, rnk Reviewed By: jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72186
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-021-1/+1
| | | | | | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling. This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28, e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows bot is a need for clearing the cache.
* Revert "build: reduce CMake handling for zlib"James Henderson2020-01-021-1/+1
| | | | | | | This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28. This commit broke the clang-x64-windows-msvc build bot and a follow-up commit did not fix it. Reverting to fix the bot.
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-011-1/+1
| | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling.
* llvm-cxxmap: fix support for remapping non-mangled names.Richard Smith2019-12-181-1/+14
| | | | | | | Remappings involving extern "C" names were already supported in the context of <local-name>s, but this support didn't work for remapping the complete mangling itself. (Eg, we would remap X<foo> but not foo itself, if foo is an extern "C" function.)
* [VFS] Disable check for ../foo on WindowsJonas Devlieghere2019-12-111-0/+2
| | | | | I'm not sure how .. is resolved on Windows. Disable it for now to make the bots happy again.
* [VFS] Extend virtual working directory testJonas Devlieghere2019-12-111-0/+25
| | | | | Extend the virtual working directory test with a few edge cases that are not currently tested.
* Implement LWG#1203 for raw_ostream.Christian Sigg2019-12-091-2/+11
| | | | | | | | | | | | | | | | | | | Implement LWG#1203 (https://cplusplus.github.io/LWG/issue1203) for raw_ostream like libc++ does for std::basic_ostream<...>. Add a operator<< overload that takes an rvalue reference of a typed derived from raw_ostream, streams the value to it and returns the stream of the same type as the argument. This allows free operator<< to work with rvalue reference raw_ostreams: raw_ostream& operator<<(raw_ostream&, const SomeType& Value); raw_os_ostream(std::cout) << SomeType(); It also allows using the derived type like: auto Foo = (raw_string_ostream(buffer) << "foo").str(); Author: Christian Sigg <csigg@google.com> Differential Revision: https://reviews.llvm.org/D70686
* [CommandLine] Add missing CallbacksDavid Green2019-12-091-0/+8
| | | | | | | | | | It appears that the cl::bits options are not used anywhere in-tree. In the recent addition to add Callback's to the options, the Callback was missing from this one. This fixes it by adding the same code from the other classes. It also adds a simple test, of sorts, just to make sure these continue compiling.
* [CommandLine] Add callbacks to OptionsDon Hinton2019-12-061-2/+64
| | | | | | | | | | | | | | | | | | | | | | Summary: Add a new cl::callback attribute to Option. This attribute specifies a callback function that is called when an option is seen, and can be used to set other options, as in option A implies option B. If the option is a `cl::list`, and `cl::CommaSeparated` is also specified, the callback will fire once for each value. This could be used to validate combinations or selectively set other options. Reviewers: beanz, thomasfinch, MaskRay, thopre, serge-sans-paille Reviewed By: beanz Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70620
* Reapply "[llvm][Support] Take in CurrentDirectory as a parameter in ↵Kadir Cetinkaya2019-12-041-100/+119
| | | | | | ExpandResponseFiles" Attemps to fix windows buildbots.
* Revert "[llvm][Support] Take in CurrentDirectory as a parameter in ↵Kadir Cetinkaya2019-12-041-98/+100
| | | | | | ExpandResponseFiles" This reverts commit 75656005dbc8866e1888932a68a830b0df403560.
* [llvm][Support] Take in CurrentDirectory as a parameter in ExpandResponseFilesKadir Cetinkaya2019-12-041-100/+98
| | | | | | | | | | | | | | | | | Summary: This is a follow-up to D70769 and D70222, which allows propagation of current directory down to ExpandResponseFiles for handling of relative paths. Previously clients had to mutate FS to achieve that, which is not thread-safe and can even be thread-hostile in the case of real file system. Reviewers: sammccall Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D70857
* [NFC][KnownBits] Add getMinValue() / getMaxValue() methodsRoman Lebedev2019-12-031-0/+14
| | | | | | | | | | As it can be seen from accompanying cleanup, it is not unheard of to write `~Known.Zero` meaning "what maximal value can this KnownBits produce". But i think `~Known.Zero` isn't *that* self-explanatory, as compared to a method with a name. Note that not all `~Known.Zero` places were cleaned up, only those where this arguably improves things.
* [unittest] Fix unittests/Support/Path.cpp after D49466Fangrui Song2019-11-261-6/+12
|
* Initial implementation of -fmacro-prefix-map and -ffile-prefix-mapDan McGregor2019-11-261-0/+29
| | | | | | | | | GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro. -ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map Reviewed By: rnk, Lekensteyn, maskray Differential Revision: https://reviews.llvm.org/D49466
* Reland 9f3fdb0d7fab: [Driver] Use VFS to check if sanitizer blacklists existIlya Biryukov2019-11-211-2/+4
| | | | | | | With updates to various LLVM tools that use SpecialCastList. It was tempting to use RealFileSystem as the default, but that makes it too easy to accidentally forget passing VFS in clang code.
* Fix uninitialized variable warning. NFC.Simon Pilgrim2019-11-181-2/+1
|
* [Support] Optimize SHA1 implementationNick Terrell2019-11-111-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add inline to the helper functions because gcc-9 won't inline all of them without the hint. I've avoided `__attribute__((always_inline))` because gcc and clang will inline without it, and improves compatibility. * Replace the byte-by-byte copy in update() with endian::readbe32() since perf reports that 1/2 of the time is spent copying into the buffer before this patch. When lld uses --build-id=sha1 it spends 30-45% of CPU in SHA1 depending on the binary (not wall-time since it is parallel). This patch speeds up SHA1 by a factor of 2 on clang-8 and 3 on gcc-6. This leads to a >10% improvement in overall linking time. lld-speed-test benchmarks run on an Intel i9-9900k with Turbo disabled on CPU 0 compiled with clang-9. Stats recorded with `perf stat -r 5`. All inputs are using `--build-id=sha1`. | Input | Before (seconds) | After (seconds) | | --- | --- | --- | | chrome | 2.14 | 1.82 (-15%) | | chrome-icf | 2.56 | 2.29 (-10%) | | clang | 0.65 | 0.53 (-18%) | | clang-fsds | 0.69 | 0.58 (-16%) | | clang-gdb-index | 21.71 | 19.3 (-11%) | | gold | 0.42 | 0.34 (-19%) | | gold-fsds | 0.431 | 0.355 (-17%) | | linux-kernel | 0.625 | 0.575 (-8%) | | llvm-as | 0.045 | 0.039 (-14%) | | llvm-as-fsds | 0.035 | 0.039 (-11%) | | mozilla | 11.3 | 9.8 (-13%) | | mozilla-gc | 11.84 | 10.36 (-12%) | | mozilla-O0 | 8.2 | 5.84 (-28%) | | scylla | 5.59 | 4.52 (-19%) | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69295
* Fix null dereference in yaml::Document::skipThomas Finch2019-11-111-0/+11
| | | | | | | | | | | | | | | | Summary: The attached test case replicates a null dereference crash in `yaml::Document::skip()`. This was fixed by adding a check and early return in the method. Reviewers: Bigcheese, hintonda, beanz Reviewed By: hintonda Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69974
* [Support] Add erase() to json::ObjectSam McCall2019-11-111-5/+32
|
* [CommandLine] Add inline ArgName printingDon Hinton2019-11-061-0/+50
| | | | | | | | | | | | | | | | | | | | | Summary: This patch adds PrintArgInline (after PrintArg) that strips the leading spaces from an argument before printing them, for usage inline. Related bug: PR42943 <https://bugs.llvm.org/show_bug.cgi?id=42943> Patch by Daan Sprenkels! Reviewers: jhenderson, chandlerc, hintonda Reviewed By: jhenderson Subscribers: hiraditya, kristina, llvm-commits, dsprenkels Tags: #llvm Differential Revision: https://reviews.llvm.org/D69501
* YAML parser robustness improvementsThomas Finch2019-11-051-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of bugs found in the YAML parser through fuzzing. In general, this makes the parser more robust against malformed inputs. The fixes are mostly improved null checking and returning errors in more cases. In some cases, asserts were changed to regular errors, this provides the same robustness but also protects release builds from the triggering conditions. This also improves the fuzzability of the YAML parser since asserts can act as a roadblock to further fuzzing once they're hit. Each fix has a corresponding test case: - TestAnchorMapError - Added proper null pointer handling in `Stream::printError` if N is null and `KeyValueNode::getValue` if getKey returns null, `Input::createHNodes` `dyn_casts` changed to `dyn_cast_or_null` so the null pointer checks are actually able to fail - TestFlowSequenceTokenErrors - Added case in `Document::parseBlockNode` for FlowMappingEnd, FlowSequenceEnd, or FlowEntry tokens outside of mappings or sequences - TestDirectiveMappingNoValue - Changed assert to regular error return in `Scanner::scanValue` - TestUnescapeInfiniteLoop - Fixed infinite loop in `ScalarNode::unescapeDoubleQuoted` by returning an error for unrecognized escape codes - TestScannerUnexpectedCharacter - Changed asserts to regular error returns in `Scanner::consume` - TestUnknownDirective - For both of the inputs the stream doesn't fail and correctly returns TK_Error, but there is no valid root node for the document. There's no reasonable way to make the scanner fail for unknown directives without breaking the YAML spec (see spec-07-01.test). I think the assert is unnecessary given that an error is still generated for this case. The `SimpleKeys.clear()` line fixes a bug found by AddressSanitizer triggered by multiple test cases - when TokenQueue is cleared SimpleKeys is still holding dangling pointers into it, so SimpleKeys should be cleared as well. Patch by Thomas Finch! Reviewers: chandlerc, Bigcheese, hintonda Reviewed By: Bigcheese, hintonda Subscribers: hintonda, kristina, beanz, dexonsmith, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61608
* TargetParserTest - testARMArch - stop bitwise operators on boolean warnings. ↵Simon Pilgrim2019-11-021-4/+5
| | | | | | NFCI. Ensure the test still runs all target checks but stop the static analyzer warnings.
* [clang][llvm] Obsolete Exynos M1 and M2Evandro Menezes2019-10-302-33/+11
|
* [ObjectYAML] - Redefine LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::yaml::Hex*) as ↵Georgii Rymar2019-10-301-7/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | LLVM_YAML_IS_FLOW_SEQUENCE_VECTOR. I am using it in https://reviews.llvm.org/D69399. This change changes how obj2yaml dumps arrays of `llvm::yaml::Hex8/llvm::yaml::Hex16/llvm::yaml::Hex32` from: ``` PayloadBytes: - 0x01 - 0x02 ... ``` To ``` PayloadBytes: [ 0x01, 0x02, ... ] ``` The latter way is shorter and looks better for arrays. Differential revision: https://reviews.llvm.org/D69558
* [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmapNick Terrell2019-10-291-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a flag `F_no_mmap` to `FileOutputBuffer` to support `--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores this flag for compatibility with GNU ld and gold. We need this flag to speed up link time for large binaries in certain scenarios. When we link some of our larger binaries we find that LLD takes 50+ GB of memory, which causes memory pressure. The memory pressure causes the VM to flush dirty pages of the output file to disk. This is normally okay, since we should be flushing cold pages. However, when using BtrFS with compression we need to write 128KB at a time when we flush a page. If any page in that 128KB block is written again, then it must be flushed a second time, and so on. Since LLD doesn't write sequentially this causes write amplification. The same 128KB block will end up being flushed multiple times, causing the linker to many times more IO than necessary. We've observed 3-5x faster builds with -no-mmap-output-file when we hit this scenario. The bad scenario only applies to compressed filesystems, which group together multiple pages into a single compressed block. I've tested BtrFS, but the problem will be present for any compressed filesystem on Linux, since it is caused by the VM. Silently ignoring --no-mmap-output-file caused a silent regression when we switched from gold to lld. We pass --no-mmap-output-file to fix this edge case, but since lld silently ignored the flag we didn't realize it wasn't being respected. Benchmark building a 9 GB binary that exposes this edge case. I linked 3 times with --mmap-output-file and 3 times with --no-mmap-output-file and took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM, BtrFS mounted with -compress-force=zstd, and an 80% full disk. | Mode | Time | |---------|-------| | mmap | 894 s | | no mmap | 126 s | When compression is disabled, BtrFS performs just as well with and without mmap on this benchmark. I was unable to reproduce the regression with any binaries in lld-speed-test. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69294
* Fix https://bugs.llvm.org/show_bug.cgi?id=43791Guillaume Chatelet2019-10-281-1/+1
|
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-242-55/+0
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-231-0/+54
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-231-54/+0
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-231-0/+54
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Fix llvm signal tests build.David Carlier2019-10-211-0/+1
| | | | llvm-svn: 375406
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-182-0/+54
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* [Error] Make llvm::cantFail include the original error messagesDon Hinton2019-10-171-7/+10
| | | | | | | | | | | | | | | | Summary: The current implementation eats the current errors and just outputs the message parameter passed to llvm::cantFail. This change appends the original error message(s), so the user can see exactly why cantFail failed. New logic is conditional on NDEBUG. Reviewed By: lhames Tags: #llvm Differential Revision: https://reviews.llvm.org/D69057 llvm-svn: 375176
* Reapply r375051: [support] GlobPattern: add support for `\` and `[!...]`, ↵Jordan Rupprecht2019-10-171-38/+96
| | | | | | | | | | | | | | | | | | | | | | | | and allow `]` in more places Reland r375051 (reverted in r375052) after fixing lld tests on Windows in r375126 and r375131. Original description: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 llvm-svn: 375149
* Revert [support] GlobPattern: add support for `\` and `[!...]`, and allow ↵Jordan Rupprecht2019-10-161-96/+38
| | | | | | | | | | `]` in more places This reverts r375051 (git commit a409afaad64ce83ea44cc30ee5f96b6e613a6e98) The patch does not work on Windows due to `\` in filenames being interpreted as escaping rather than literal path separators when used by lld linker scripts. llvm-svn: 375052
* [support] GlobPattern: add support for `\` and `[!...]`, and allow `]` in ↵Jordan Rupprecht2019-10-161-38/+96
| | | | | | | | | | | | | | | | | | | | | | | | more places Summary: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 undo objcopy changes to make this libsupport only llvm-svn: 375051
* Fix an unused variable introduced in rL374955 / rG21703543.David L. Jones2019-10-161-0/+1
| | | | | | Even though this is a unit test, it still may be run under optimization. llvm-svn: 374961
* [Reland][VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-4/+171
| | | | | | | | | | | | | | | | | | | | RedirectingFS Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374955
* Revert "[VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-171/+4
| | | | | | | | | | | RedirectingFS" This reverts the original commit and the follow up: Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS" Revert "[test] Update YAML mapping in VirtualFileSystemTest" llvm-svn: 374935
OpenPOWER on IntegriCloud