Cherry-pick profile runtime & lldb build fixes #203
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The debugserver build needs to conditionally include files depending on the target architecture. Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as the llvm and swift build systems use this variable to identify the target (the latter, indirectly, through LLVM_HOST_TRIPLE). It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift build does not provide it, preferring instead to pass arch-specific CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option, but it breaks down when cross-compiling. Differential Revision: https://reviews.llvm.org/D69523 (cherry picked from commit 82d3ba8)
`LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it may actually be unset. Furthermore, in standalone builds, the variable may be fully undefined. Apply the regular expression over the empty string in such a case. This should improve the state of the green dragon bot. (cherry picked from commit 55eec2b)
When building standalone, `LLVM_DEFAULT_TARGET_TRIPLE` may be undefined. Matching against an empty string does not work as desired in CMake, so, fallback to the old behaviour, defaulting `LLDB_DEBUGSERVER_ARCH` to `CMAKE_OSX_ARCHITECTURES`. (cherry picked from commit 5e029c4)
(cherry picked from commit ade776b)
As pointed out in https://reviews.llvm.org/D66979 post-commit, making this test textual would make it more maintainable. Differential Revision: https://reviews.llvm.org/D68718 llvm-svn: 374617 (cherry picked from commit 852e3b2)
…se arm bots There are a number arm bots failing after r374617 landed, and I'm not sure why. It looks a bit like the error message llvm-profdata is expected to print to stderr isn't flushed. Weaken the test in an attempt to appease the arm bots: if this doesn't work, that means that llvm-profdata is actually *not failing*, and that will be a clear indication that some logic error is actually happening. http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/5604/ llvm-svn: 374792 (cherry picked from commit eef612b)
…rray.test This test is still failing on the ARM bots and I need time to investigate. llvm-svn: 374915 (cherry picked from commit e409f12)
…r-array.test I removed this test to unblock the ARM bots while looking into failures (r374915), and am reinstating it now with a fix. I believe the problem was that counter ptr address I used, '\0\0\6\0\1\0\0\1', set the high bits of the pointer, not the low bits like I wanted. On x86_64 this superficially looks like it tests r370826, but it doesn't, as it would have been caught before r370826. However, on ARM (or, 32-bit hosts more generally), I suspect the high bits were cleared, and you get a 'valid' profile. I verified that setting the *low* bits of the pointer does trigger the new condition: -// Note: The CounterPtr here is off-by-one. This should trigger a malformed profile error. -RUN: printf '\0\0\6\0\1\0\0\1' >> %t.profraw +// Note: The CounterPtr here is off-by-one. +// +// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters, +// the profile reader should error out. +RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw This reverts commit c7cf5b3e4b918c9769fd760f28485b8d943ed968. llvm-svn: 374927 (cherry picked from commit c7ec51a)
…ile. Summary: User code can open a file on its own and pass it to the runtime, rather than specifying a name and having the runtime open the file. This supports the use case where a process cannot open a file on its own but can receive a file descriptor from another process. Relanding https://reviews.llvm.org/D62541. The original revision unlocked the file before calling flush, this revision fixes that. Reviewers: Dor1s, davidxl Reviewed By: Dor1s Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D63581 llvm-svn: 364231 (cherry picked from commit 6694b2b)
When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 llvm-svn: 375301 (cherry picked from commit 937241b)
The Windows bots are failing with: clang: warning: argument unused during compilation: '-dynamiclib' [-Wunused-command-line-argument] llvm-svn: 375315 (cherry picked from commit f6a4630)
This is more portable than -dynamiclib. Also, fix the path to an input file that broke when the test was moved in r375315. llvm-svn: 375317 (cherry picked from commit b081220)
Add support for continuously syncing profile counter updates to a file. The motivation for this is that programs do not always exit cleanly. On iOS, for example, programs are usually killed via a signal from the OS. Running atexit() handlers after catching a signal is unreliable, so some method for progressively writing out profile data is necessary. The approach taken here is to mmap() the `__llvm_prf_cnts` section onto a raw profile. To do this, the linker must page-align the counter and data sections, and the runtime must ensure that counters are mapped to a page-aligned offset within a raw profile. Continuous mode is (for the moment) incompatible with the online merging mode. This limitation is lifted in https://reviews.llvm.org/D69586. Continuous mode is also (for the moment) incompatible with value profiling, as I'm not sure whether there is interest in this and the implementation may be tricky. As I have not been able to test extensively on non-Darwin platforms, only Darwin support is included for the moment. However, continuous mode may "just work" without modification on Linux and some UNIX-likes. AIUI the default value for the GNU linker's `--section-alignment` flag is set to the page size on many systems. This appears to be true for LLD as well, as its `no_nmagic` option is on by default. Continuous mode will not "just work" on Fuchsia or Windows, as it's not possible to mmap() a section on these platforms. There is a proposal to add a layer of indirection to the profile instrumentation to support these platforms. rdar://54210980 Differential Revision: https://reviews.llvm.org/D68351 (cherry picked from commit d889d1e)
setenv() appears to not be available on Windows: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/53545/steps/stage%201%20build/logs/stdio (cherry picked from commit aa7f3a4)
VLAs in C appear to not work on Windows, so use COMPILER_RT_ALLOCA: C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2057: expected constant expression C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2466: cannot allocate an array of constant size 0 C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2133: 'Zeroes': unknown size (cherry picked from commit 6dfe8e5)
_putenv on Windows takes 1 argument, whereas setenv elsewhere takes 3. Just treat the two platforms differently. http://lab.llvm.org:8011/builders/sanitizer-windows/builds/53547 (cherry picked from commit a49795d)
Fix llvm/test/tools/llvm-profdata/nocompress.test, which I missed when authoring D68351 because my toolchain is configured with zlib support. (cherry picked from commit fd3d450)
Use the printf macros from inttypes.h to sidestep -Wformat issues:
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:425:14: error: format specifies type 'long long' but the argument has type 'off_t' (aka 'long') [-Werror,-Wformat]
CurrentFileOffset, PageSize);
^~~~~~~~~~~~~~~~~
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR'
fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__);
~~~~~~ ^~~~~~~~~~~
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:461:41: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
strerror(errno), CountersBegin, PageAlignedCountersLength, Fileno,
^~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR'
fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__);
~~~~~~ ^~~~~~~~~~~
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:462:9: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
FileOffsetToCounters);
^~~~~~~~~~~~~~~~~~~~
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR'
fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__);
(cherry picked from commit 197bad5)
Finding the call edge in a function which corresponds to a particular return address is a generic/useful operation. llvm-svn: 371543 (cherry picked from commit ff02109)
llvm-svn: 371544 (cherry picked from commit 3ef7dbd)
…_LOGF) llvm-svn: 371667 (cherry picked from commit bb58118)
The swift build system has support for cross-compiling, installing, and generating symbols for lldb. As the swift symbol-generation step occurs after installation, we need to disable stripping during the install. (cherry picked from commit 610f80f)
Summary: After D68351 we need this to make builds with `-DBUILD_SHARED_LIB=ON` work. Reviewers: tlively Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69699 (cherry picked from commit b9903ec)
This test remains flaky everywhere, I think. We should consider deleting it and accompanying support code in GCOVProfiling: I've stopped short of doing that now as the gcov exec* tests appear to be stable. See the thread re: r347779. llvm-svn: 373121 (cherry picked from commit 9639f35)
|
@swift-ci test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.