It seems this CL broke lldb cmake build - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/17910/steps/ninja%20build%20local/logs/stdio, could you take a look?
Aug 25 2016
Aug 6 2016
Aug 5 2016
Looks like this CL broke LLDB cmake buildbot - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/17873/steps/ninja%20build%20local/logs/stdio, could you take a look?
Aug 2 2016
It seems this CL is breaking lldb cmake build - could you take a look?
Jul 21 2016
Jul 12 2016
Jul 8 2016
/lldb/trunk/source/Plugins/Platform/Android/AdbClient.cpp /lldb/trunk/source/Plugins/Platform/Android/AdbClient.h /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
Thanks for adding the additional checks. Looks good apart from the clang-format changes. This looks like the llvm style. I am not sure how you've run this but it does not seem to have picked up LLDB's .clang-format file.
Are you using git? You need to set clangFormat.binary setting to a sufficient new version (ideally the one you've just built), so it knows how to handle our AlwaysBreakAfterReturnType: All format. Then git clang-format HEAD^ should just work (assuming you have git-clang-format in your path).
Reran with proper clang-format.
Jul 7 2016
You raised good points here, Luke.
I've thought about the quoting issue, but as you have already noticed there is no way to pass arguments containing quotes to adb correctly. Thinking about it more, what we could do is detect this situation (look for ' in the file name) and abort the whole process even before issuing the "adb shell" command.
As for the return value, this should not be a big problem, as further down the line we will discover that this is not a real ELF file and ignore it, but perhaps we could help here by searching for the file name in the first 1K bytes of the result, and ignoring the file if we find it?
Oleksiy, what do you think?
Addressed review comments:
- Check whether shell command output starts with /system/bin/sh: in order to find out whether command failed
- Fail-fast download if filename contains single-quotes
Jul 6 2016
/lldb/trunk/source/Plugins/Platform/Android/AdbClient.cpp /lldb/trunk/source/Plugins/Platform/Android/AdbClient.h /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
Jul 5 2016
Jun 30 2016
/lldb/trunk/source/Plugins/Platform/Android/AdbClient.cpp /lldb/trunk/source/Plugins/Platform/Android/AdbClient.h /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
If you okay with that I'd like to submit this CL as-is and come up with unit test with a separate change list.
Jun 29 2016
Is AdbClient getting big enough to deserve a couple of unit tests? All it would take is to add the ability to specify the address to connect to and make a small mock server that listens at that address?
Jun 27 2016
Jun 24 2016
May 27 2016
This change broke connection to debugserver on OS X - the constructed URL on debugserver does not take the tcp:// (URL-scheme) portion. This would manifest when 'lldb-server platform' was attempting to launch debugserver.
I'm going to be making a fix for the debugserver case. I'll make sure it doesn't break Linux.
May 24 2016
Submitted as r270590
At some point we should probably make a host layer call like:
const char *const char *Host::GetIllegalFilenameCharacters();" so that each host can determine the correct thing for the current host. Then FileSpec can be updated to use this function handle this with a method like "void FileSpec::NormalizePathForHost()". This will probably need to be done elsewhere.
According to https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396, characters with codes 1..31 (basically < ' '), are illegal as well. We might as well convert those, just in case.
Agree - done.
I've been sitting on a unit test for the module cache locally for a while now... I guess it's time to put that in, and then we can add a test for this as well.
Added the check for symbol in [1;31] range.
May 23 2016
Added asterisk symbol
May 16 2016
Thank you, Sean.
May 15 2016
I reverted this CL with r269575 because of test failures on CMake and Android buildbots - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14699. Feel free to re-submit it once the test issue is resolved.
May 14 2016
May 12 2016
Looks like this CL broke CMake build bot - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14634, could you take a look?
May 9 2016
Looks like this CL broke CMake buildbot - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14464, could you take a look?
May 4 2016
Apr 28 2016
Apr 27 2016
Apr 26 2016
Apr 16 2016
Apr 14 2016
we have bunch of new failures on LLDB cmake build bot with ToT - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/13420
It's failing due clang issue - CalledProcessError: Command 'make ARCH=x86_64 CC="/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang" ' returned non-zero exit status 2
Is it possible that it's caused by this your CL?
Why is this necessary? stdout is a local variable defined in this scope. Why would the android g++ have problems with this?
Anyway, if you have to avoid using stdout as a name, maybe name it std_out as that better reflects its meaning.
Apr 13 2016
Submitted as http://reviews.llvm.org/rL266274
Apr 12 2016
It seems this CL is breaking LLDB Windows builder - http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/5228, could you take a look?
It seems this CL made TestDebugBreak to fail on x86_64 on darwin build bot - http://lab.llvm.org:8011/builders/lldb-x86_64-darwin-13.4/builds/9529. Do we need to revert it for now?
Apr 11 2016
FYI: According to git bisect, this patch seems to have introduced a new test failure on Windows.
Apr 8 2016
it seems cmake build bot started to fail after this CL - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/13203. Could you take a look?
Submitted as http://reviews.llvm.org/rL265843
Does this fix an existing test or is a new issue? If it's new (it sounds like it is, as I don't see any test failures), could you also add a test for this. It shouldn't be too difficult to write one... Would something like this:dbg.SetAsync(true) process.Continue() lldbutil.expect_state_changes(self,dbg.GetListener(), [eStateRunning]) target.BreakpointCreateBySourceRegex("// some code which will not get executed by the inferior") do_some_assertions_on_the_breakpoint() while dbg.GetListener().WaitForEvent(2, event): if SBProcess.GetStateFromEvent(event) == eStateStopped and SBProcess.GetRestartedFromEvent(state): continue if SBProcess.GetStateFromEvent(event) == eStateRunning: continue self.fail("Setting a breakpoint generated an unexpected event: %s"%SBDebugger.StateAsCString(SBProcess.GetStateFromEvent(event)));
do the trick?
Added new TestBreakpointSetRestart test to cover the addressed issue.
Apr 7 2016
Mar 19 2016
looks like this CL broke Windows build bot - http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/4882.
Could you take a look?
Feb 25 2016
Feb 22 2016
Feb 18 2016
It seems this CL broke LLDB CMake build bot - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11554
Could you take a look?
Feb 16 2016
It seems this CL broke LLDB Windows buildbot - http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/4316
Could you take a look?
Feb 12 2016
Feb 11 2016
Feb 3 2016
Submitted as http://reviews.llvm.org/rL259714
Jan 29 2016
Jan 23 2016
CL is failing on lldb cmake buildbot - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10660
Jan 22 2016
Jan 20 2016
It seems lldb xcode build started to fail after this CL - http://lab.llvm.org:8011/builders/lldb-x86_64-darwin-13.4/builds/8218
Jan 19 2016
Submitted as http://reviews.llvm.org/rL258150
Jan 15 2016
Jan 13 2016
If vdso bug pertains to ELF format then it looks reasonable to keep the fix within ObjectFileELF.
I experimented a while ago with making ObjectFileELF to read from arbitrary offsets - please see http://reviews.llvm.org/D16151 as reflection of this idea (patch is pretty old and cannot be applied as-is).
Please take a look into it and let us know whether such approach may solve vdso problem.
Jan 12 2016
vdso issue is related to ELF format and I'm wondering whether we can keep the fix contained in ObjectFileELF - for example, if a section that we're trying to read is beyond the boundaries of memory buffer we can read its content from inferior's memory using ObjectFile::m_process_wp.
Jan 11 2016
Dec 15 2015
Dec 11 2015
Dec 10 2015