- User Since
- Apr 28 2017, 8:23 AM (142 w, 22 h)
Fri, Jan 10
Thu, Jan 9
Stop iterating when reach the top-level test folder
Mon, Jan 6
Increased number of lines of context.
Thu, Dec 26
Dec 9 2019
Dec 5 2019
Nov 21 2019
Nov 12 2019
Nov 1 2019
I mean, when a process is not able to allocate memory, it cannot JIT, but still can interpret. Should the test report failure in this case?
Another problem of the test_ir_interpreter is that it fails even when JIT fails despite it should test the interpreter.
Oct 17 2019
Rebased on the current trunk.
Removed any ARC-specific logic from the ProcessGDBRemote.cpp.
Oct 15 2019
Build and installation completed successfully! LGTM, though it would be good if anyone tests this with Xcode.
Oct 14 2019
@hhb, please, take a look. Slightly changed your patch to make it work for Visual Studio.
Oct 12 2019
Oct 11 2019
Fixed by reverting the initial commit.
Oct 10 2019
Please see my comment D68719#1703785.
Oct 9 2019
Oct 8 2019
I have longed for this change, thank you!
Sep 26 2019
Sep 25 2019
Removed using UnixSignals::ShouldSuppress, just check if a signal is either SIGINT or SIGSTOP.
To Pavel: this problem is not only about the behavior of process attach, but for process launch too (and possibly something else). That's why I'm trying to move this logic out of specific commands.
Sep 24 2019
Sep 20 2019
Added a test
The flag m_abnormal_stop_was_expected was added in the commit to avoid stop on crash because attach always stops
with a SIGSTOP on OSX. I faced the same issue with SIGTRAP and SIGSTOP sent by a gdb-remote stub on some commands. This patch filters out such harmless signals instead of setting the flag everywhere in commands.
Sep 19 2019
Aug 27 2019
Aug 26 2019
A few typos remained after copy-pasting
Macros __x86_64__ and _M_X64 are more common than AMD-branded, though there is no functional difference (unless using old versions of the Intel compiler).
Aug 24 2019
Jul 31 2019
Jul 30 2019
I wonder if directories x86 and x64 are needed. Should I remove them to make hierarchy consistent with D63165?
Jul 29 2019
Jun 21 2019
@beanz you're absolutely right, thank you.
Jun 20 2019
There is a workaround D63544 for fixing the issue in lldb/unittests/tools/lldb-mi/utils/CMakeLists.txt without changing the minimum required cmake's version.
Finally updated versions - target_sources supports using $<TARGET_OBJECTS:...> since CMake 3.5.0.
Jun 19 2019
As I figured out, cmake allows to use $<TARGET_OBJECTS:...> anywhere since version 3.9 (commit).
It will cause some time overhead for linking a library. Linking is already formidable for the project and I'd avoid it when possible.
Jun 10 2019
May 21 2019
Apr 26 2019
Apr 3 2019
Hi, currently we have a private build server that executes the test-suite on ARC. There are failures for now, mostly due to unimplemented features for ARC like expressions support.
I'll take care of a public build-bot, if it is required.
Mar 27 2019
Mar 26 2019
Kind reminder. I believe all discussions have been resolved.
Mar 6 2019
Run into a few compilation errors building on Windows with msvc.
Mar 5 2019
Mar 1 2019
Feb 26 2019
Feb 25 2019
Removed new lines from MIUtilString.h
Feb 20 2019
LLDB_PROJECT_ROOT -> LLDB_SOURCE_DIR
Thanks for the review!
Feb 16 2019
Thank you for mentioning StringRef, you gave me the idea to keep pointers check inside the CMIUtilString to obviate undefined behavior. This is the best place to do it, however, a caller still should examine pointers he passes to CMIUtilString::Format as the ellipsis parameter.
Feb 14 2019
Thanks for the review!
Feb 11 2019
Yes, of course!
These also don't relate directly but intersect with your changes:
A few modernizations which though don't directly relate to make_shared: