[lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

Hello, trying a test deployment of a buildbot but I do not see how to deploy the final: upload test traces './uploadTestTrace.sh 43 ...' failed ( 10 secs ) http://lab.llvm.org:8014/builders/lldb-x86_64-fedora-28-cmake/builds/43/steps/upload%20test%20traces/logs/stdio I was follow

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

This step is very specific to our (android studio) buildbot setup, and it uploads the test results to a google cloud account only accessible to our team. If you wanted to do something like that, you'd have to create your own account and set it up similarly. However, I strongly suspect that you do

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote: > However, I strongly suspect that you do not want this, Right. > *However*, for setting up a new bot, I'd recommend not using this > particular slave factory (getLLDBScriptCommandsFactory) at all, > because it's heavily customized for our

Re: [lldb-dev] buildbot deployment: gsutil: Anonymous caller does not have storage.objects.create access to lldb_test_traces

On Thu, 2 Aug 2018 at 13:39, Jan Kratochvil wrote: > > On Thu, 02 Aug 2018 13:47:25 +0200, Pavel Labath wrote: > > However, I strongly suspect that you do not want this, > > Right. > > > > *However*, for setting up a new bot, I'd recommend not using this > > particular slave factory (getLLDBScript

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

Why weren't my local LLVM & LLDB builds able to decompress the sections? CMake! Remembering to delete CMakeCache.txt is usually the part I forget to do. LLDB tried to decompress, but when failed to do so it carried on returning and alter attempting to parse the compressed bytes as is. A section

[lldb-dev] Firewall complaint about hosttests.exe

Windows Firewall popped a message that hosttests.exe was doing something that the firewall decided to block. I just enabled lldb as a project in my build last night, so I hadn't seen this before. I'm inclined to think it's doing a local/remote communication thing, but I wouldn't expect it to tick

Re: [lldb-dev] Firewall complaint about hosttests.exe

Yes, we have a couple of tests there, which verify that our socket communication works. It seems there is one test which specifically opens a non-localhost socket (TCPListen0GetPort (*)), so I would bet it's that's the one the firewall is having problems with. Or, if you have a particularly paranoi

Re: [lldb-dev] Phabricator repository

Thanks a lot for adding this! - Raphael Am Do., 2. Aug. 2018 um 02:12 Uhr schrieb Eric Liu : > > Sorry for the late response. I have created a repository for LLDB on > phabricator: https://reviews.llvm.org/source/lldb/. Let me know if there is > anything else I could help with. > > On Wed, Aug 1

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

Thanks Paul! I have a fix for the LLDB handling of compressed sections in an upcoming change (together with improved logging). The email was mostly in case some other poor soul hit the same problem (until I get a chance to commit the fixes) *(*) none of the tools bothered to make a note that the s

Re: [lldb-dev] Where "thread until " should set breakpoints?

That's a bug. The code in CommandObjectThreadUntil needs to be a little more careful about sliding the line number to the "nearest source line that has code." It currently does: for (uint32_t line_number : line_numbers) { uint32_t start_idx_ptr = index_ptr; while (s

Re: [lldb-dev] Where "thread until " should set breakpoints?

> On Aug 2, 2018, at 10:26 AM, Jim Ingham via lldb-dev > wrote: > > I think the better behavior is to try FindLineEntry the first time with exact > = false. If that picks up a different line from the one given, reset the > line we are looking for to the found line. In either case, then go

[lldb-dev] run tests with ASAN (dotest.py)

Hi, I'd like to run the tests, when LLVM, Clang and LLDB are all built with ASAN. I am using release_60 version of LLDB. The unittests just run fine, but with `dotest.py`, there is an error. Maybe the LLDB build does not respect the global -DLLVM_USE_SANITIZER flag of cmake ? Any help would be ap

Re: [lldb-dev] run tests with ASAN (dotest.py)

Hi Gábor, That symbol appears to be defined in compiler-rt/lib/asan/asan_rtl.cc , so it should be provided by the asan runtime. Are you sure that the runtime expected by the host compiler is being dynamically loaded here? You can check this using 'ldd' (IIRC) on Linux or 'o

Re: [lldb-dev] Where "thread until " should set breakpoints?

Thanks Jim for the elaborate reply. I knew what is happening in below piece of code and also has a patch ready but now needs a bit of fine tuning based on your below comments. I just wanted to hear from you folks that my understanding is correct and I am not missing something. Also, the code arou