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

[Venkata Ramanaiah Nalamothu via lldb-dev]

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 around it needs modification of error messages to refer to
'thread->GetID()' instead of 'm_options.m_thread_idx'. I will create a
review on phabricator with all these changes.

- Ramana

On Thu, Aug 2, 2018 at 10:56 PM, Jim Ingham  wrote:

> 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 (start_idx_ptr <= end_ptr) {
> LineEntry line_entry;
> const bool exact = false;
> start_idx_ptr = sc.comp_unit->FindLineEntry(
> start_idx_ptr, line_number, sc.comp_unit, exact,
> _entry);
> if (start_idx_ptr == UINT32_MAX)
>   break;
>
> addr_t address =
> line_entry.range.GetBaseAddress().GetLoadAddress(target);
> if (address != LLDB_INVALID_ADDRESS) {
>   if (fun_addr_range.ContainsLoadAddress(address, target))
> address_list.push_back(address);
>   else
> all_in_function = false;
> }
> start_idx_ptr++;
>   }
> }
>
> The problem is that in the while loop we set:
>
> const bool exact = false;
>
> Having exact == false through the whole loop means that all the other line
> table entries after the last exact match will match because from the index
> ptr on there are no more entries, so we slide it to the next one.
>
> In general it's not always easy to tell which lines will actually
> contribute code so lldb is lax about line number matching, and slides the
> breakpoint to the nearest subsequent line that has code when there's no
> exact match.  That seems a good principle to follow here as well.  So I
> don't want to just set exact to "true".
>
> 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 on
> to search for all the other instances of that line with exact = false.  It
> might actually be handy to have another function on CompUnit like
> FindAllEntriesForLine that bundles up this behavior as it seems a generally
> useful one.
>
> If you want to give this a try, please do.  Otherwise, file a bug and I'll
> get to it when I have a chance.
>
> Jim
>
>
>
> > On Aug 1, 2018, at 10:22 PM, Ramana  wrote:
> >
> >
> > On Thu, Aug 2, 2018 at 3:32 AM, Jim Ingham  wrote:
> >
> >
> > > On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > On the subject line, the ToT lldb (see code around
> CommandObjectThread.cpp:1230) sets the breakpoint on the first exact
> matching line of 'line-number' or the closest line number > 'line-number'
> i.e. the best match.
> > >
> > > And along with that, starting from the above exact/best matching line
> number index in the line table, the breakpoints are also being set on every
> other line number available in the line table in the current function
> scope. This latter part, I believe, is incorrect.
> >
> > Why do you think this is incorrect?
> >
> > The requirements for "thread until " are:
> >
> > a) If any code contributed by  is executed before leaving
> the function, stop
> > b) If you end up leaving the function w/o triggering (a), then stop
> >
> > Understood and no concerns on this.
> >
> > Correct or incorrect should be determined by how well the implementation
> fits those requirements.
> >
> > There isn't currently a reliable indication from the debug information
> or line tables that "line N will always be entered starting with the block
> at 0x123".  So you can't tell without doing control flow analysis, which if
> any of the separate entries in the line table for the same line will get
> hit in the course of executing the function.  So the safest thing to do is
> to set breakpoints on them all.
> >
> > From the above, I understand that we have to do this when the debug line
> table has more than one entry for a particular source line. And this is
> what I referred to as "machine code for one single source line is scattered
> across" in my previous mail. Thanks for sharing why we had to do that.
> >
> > Besides setting a few more breakpoints - which should be pretty cheap -
> I don't see much downside to the way it is currently implemented.
> >
> > Anyway, why did this bother you?
> >
> > Jim
> >
> > However, I am concerned about the below 'thread until' behaviour. For
> the attached test case 

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

[Vedant Kumar via lldb-dev]

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 'otool -l' on Darwin. 
Also, did you take the extra step needed to preload the runtime 
(LD_PRELOAD/DYLD_INSERT_LIBRARIES)?

best,
vedant


> On Aug 2, 2018, at 12:24 PM, Gábor Márton via lldb-dev 
>  wrote:
> 
> 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 appreciated,
> Thanks,
> Gabor
> 
> 
> ```
> /var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py
> --executable /var/jenkins_home/workspace/ctu_pipeline/build/bin/lldb
> /var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/
> -v --excluded ./lldb_test_exclude
> lldb version 6.0.0 (https://github.com/llvm-mirror/lldb.git revision
> b6df24ff1b258b18041161b8f32ac316a3b5d8d9)
>  clang revision 64eed461cdd3705e7bc1ccc95df9858f7fe216a8
>  llvm revision 089d4c0c490687db6c75f1d074e99c4d42936a50
> ['/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py',
> '--executable',
> '/var/jenkins_home/workspace/ctu_pipeline/build/bin/lldb',
> '/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/',
> '-v', '--excluded', './lldb_test_exclude']
> LLDB library dir: /var/jenkins_home/workspace/ctu_pipeline/build/bin
> LLDB import library dir: /var/jenkins_home/workspace/ctu_pipeline/build/bin
> The 'lldb-mi' executable cannot be located.  The lldb-mi tests can not
> be run as a result.
> Traceback (most recent call last):
>  File 
> "/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py",
> line 7, in 
>lldbsuite.test.run_suite()
>  File 
> "/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 1129, in run_suite
>import lldb
>  File 
> "/var/jenkins_home/workspace/ctu_pipeline/build/lib/python2.7/site-packages/lldb/__init__.py",
> line 53, in 
>_lldb = swig_import_helper()
>  File 
> "/var/jenkins_home/workspace/ctu_pipeline/build/lib/python2.7/site-packages/lldb/__init__.py",
> line 49, in swig_import_helper
>_mod = imp.load_module('_lldb', fp, pathname, description)
> ImportError: 
> /var/jenkins_home/workspace/ctu_pipeline/build/lib/libLLVMDemangle.so.6:
> undefined symbol: __asan_option_detect_stack_use_after_return
> 
> ```
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Gábor Márton via lldb-dev]

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 appreciated,
Thanks,
Gabor


```
/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py
--executable /var/jenkins_home/workspace/ctu_pipeline/build/bin/lldb
/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/
-v --excluded ./lldb_test_exclude
lldb version 6.0.0 (https://github.com/llvm-mirror/lldb.git revision
b6df24ff1b258b18041161b8f32ac316a3b5d8d9)
  clang revision 64eed461cdd3705e7bc1ccc95df9858f7fe216a8
  llvm revision 089d4c0c490687db6c75f1d074e99c4d42936a50
['/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py',
'--executable',
'/var/jenkins_home/workspace/ctu_pipeline/build/bin/lldb',
'/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/',
'-v', '--excluded', './lldb_test_exclude']
LLDB library dir: /var/jenkins_home/workspace/ctu_pipeline/build/bin
LLDB import library dir: /var/jenkins_home/workspace/ctu_pipeline/build/bin
The 'lldb-mi' executable cannot be located.  The lldb-mi tests can not
be run as a result.
Traceback (most recent call last):
  File 
"/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/test/dotest.py",
line 7, in 
lldbsuite.test.run_suite()
  File 
"/var/jenkins_home/workspace/ctu_pipeline/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
line 1129, in run_suite
import lldb
  File 
"/var/jenkins_home/workspace/ctu_pipeline/build/lib/python2.7/site-packages/lldb/__init__.py",
line 53, in 
_lldb = swig_import_helper()
  File 
"/var/jenkins_home/workspace/ctu_pipeline/build/lib/python2.7/site-packages/lldb/__init__.py",
line 49, in swig_import_helper
_mod = imp.load_module('_lldb', fp, pathname, description)
ImportError: 
/var/jenkins_home/workspace/ctu_pipeline/build/lib/libLLVMDemangle.so.6:
undefined symbol: __asan_option_detect_stack_use_after_return

```
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

> 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 on to 
> search for all the other instances of that line with exact = false.  It might 
> actually be handy to have another function on CompUnit like 
> FindAllEntriesForLine that bundles up this behavior as it seems a generally 
> useful one.

That should be "search for all the other instances of that line with exact = 
true"...


Jim

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

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 (start_idx_ptr <= end_ptr) {
LineEntry line_entry;
const bool exact = false;
start_idx_ptr = sc.comp_unit->FindLineEntry(
start_idx_ptr, line_number, sc.comp_unit, exact, _entry);
if (start_idx_ptr == UINT32_MAX)
  break;

addr_t address =
line_entry.range.GetBaseAddress().GetLoadAddress(target);
if (address != LLDB_INVALID_ADDRESS) {
  if (fun_addr_range.ContainsLoadAddress(address, target))
address_list.push_back(address);
  else
all_in_function = false;
}
start_idx_ptr++;
  }
}

The problem is that in the while loop we set:

const bool exact = false;

Having exact == false through the whole loop means that all the other line 
table entries after the last exact match will match because from the index ptr 
on there are no more entries, so we slide it to the next one.

In general it's not always easy to tell which lines will actually contribute 
code so lldb is lax about line number matching, and slides the breakpoint to 
the nearest subsequent line that has code when there's no exact match.  That 
seems a good principle to follow here as well.  So I don't want to just set 
exact to "true".

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 on to search for 
all the other instances of that line with exact = false.  It might actually be 
handy to have another function on CompUnit like FindAllEntriesForLine that 
bundles up this behavior as it seems a generally useful one.

If you want to give this a try, please do.  Otherwise, file a bug and I'll get 
to it when I have a chance.

Jim



> On Aug 1, 2018, at 10:22 PM, Ramana  wrote:
> 
> 
> On Thu, Aug 2, 2018 at 3:32 AM, Jim Ingham  wrote:
> 
> 
> > On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev  
> > wrote:
> > 
> > On the subject line, the ToT lldb (see code around 
> > CommandObjectThread.cpp:1230) sets the breakpoint on the first exact 
> > matching line of 'line-number' or the closest line number > 'line-number' 
> > i.e. the best match.
> > 
> > And along with that, starting from the above exact/best matching line 
> > number index in the line table, the breakpoints are also being set on every 
> > other line number available in the line table in the current function 
> > scope. This latter part, I believe, is incorrect.
> 
> Why do you think this is incorrect?  
> 
> The requirements for "thread until " are:
> 
> a) If any code contributed by  is executed before leaving the 
> function, stop
> b) If you end up leaving the function w/o triggering (a), then stop
> 
> Understood and no concerns on this.
>  
> Correct or incorrect should be determined by how well the implementation fits 
> those requirements.
> 
> There isn't currently a reliable indication from the debug information or 
> line tables that "line N will always be entered starting with the block at 
> 0x123".  So you can't tell without doing control flow analysis, which if any 
> of the separate entries in the line table for the same line will get hit in 
> the course of executing the function.  So the safest thing to do is to set 
> breakpoints on them all.
> 
> From the above, I understand that we have to do this when the debug line 
> table has more than one entry for a particular source line. And this is what 
> I referred to as "machine code for one single source line is scattered 
> across" in my previous mail. Thanks for sharing why we had to do that.
> 
> Besides setting a few more breakpoints - which should be pretty cheap - I 
> don't see much downside to the way it is currently implemented.
> 
> Anyway, why did this bother you?
> 
> Jim
> 
> However, I am concerned about the below 'thread until' behaviour. For the 
> attached test case (kernels.cpp - OpenCL code), following is the debug line 
> table generated by the compiler.
> 
> File nameLine numberStarting address
> ./kernels.cpp:[++]
> kernels.cpp9   0xacc74d00
> kernels.cpp   12  0xacc74d00 
> kernels.cpp   14  0xacc74d40
> kernels.cpp   13  0xacc74dc0
> kernels.cpp   14  0xacc74e00
> kernels.cpp   25  0xacc74e80
> kernels.cpp 

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

[Leonard Mosescu via lldb-dev]

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 sections are
> compressed (*
> *SHF_COMPRESSED)*That seems like a completely valid feature request.
> Again filing a bug would be the right tactic.  I'm willing to do this one
> for you, if you don't have a bugzilla account.


I'll open a request for llvm-dwarfdump. If you happen to be in touch with
the developers of the other tools (readelf, objdump, dwarfdump) feel free
to forward them the notes.




On Thu, Aug 2, 2018 at 7:21 AM,  wrote:

> 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 that is compressed but can't be decompressed should be treated
> as corrupt/unparseable.  That seems like an LLDB bug; do you have an
> account on the project bugzilla?
>
>
>
> *(*) none of the tools bothered to make a note that the sections are
> compressed (**SHF_COMPRESSED)*
>
>
>
> That seems like a completely valid feature request.  Again filing a bug
> would be the right tactic.  I'm willing to do this one for you, if you
> don't have a bugzilla account.
>
>
>
> Thanks,
>
> --paulr
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Phabricator repository

[Raphael Isemann via lldb-dev]

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, 2018 at 7:07 PM Raphael Isemann  wrote:
>>
>> Ah, my bad, that makes more sense. I dropped them an email with the request.
>>
>> - Raphael
>> Am Mi., 1. Aug. 2018 um 09:58 Uhr schrieb :
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: Raphael Isemann [mailto:teempe...@gmail.com]
>> > > Sent: Wednesday, August 01, 2018 12:21 PM
>> > > To: Robinson, Paul
>> > > Cc: Pavel Labath; ioe...@google.com; LLDB Dev
>> > > Subject: Re: [lldb-dev] Phabricator repository
>> > >
>> > > The list is not public, so someone with access needs to mail them
>> > > (which is not true for me :) ).
>> >
>> > This is the prescribed method for admin-style requests.  If you're
>> > not subscribed to llvm-admin, the message goes to the moderation
>> > queue, and it will still be seen.  Anyone is supposed to be able
>> > to make a request.
>> > --paulr
>> >
>> > >
>> > > - Raphael
>> > > Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb :
>> > > >
>> > > > Email to llvm-admin should do it.
>> > > > --paulr
>> > > >
>> > > > > -Original Message-
>> > > > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
>> > > Pavel
>> > > > > Labath via lldb-dev
>> > > > > Sent: Wednesday, August 01, 2018 3:52 AM
>> > > > > To: Raphael Isemann; Eric Liu
>> > > > > Cc: LLDB
>> > > > > Subject: Re: [lldb-dev] Phabricator repository
>> > > > >
>> > > > > Sounds like a good idea, though I'm not sure what specifically needs
>> > > > > to be done to make that happen. Eric might know more...
>> > > > > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev
>> > > > >  wrote:
>> > > > > >
>> > > > > > Could we get LLDB into this repository list here?
>> > > > > > https://reviews.llvm.org/diffusion/
>> > > > > >
>> > > > > > Beside that it's a bit confusing to the user that lldb is the only
>> > > > > > missing project there, it also breaks phabricator/arcanist which
>> > > seems
>> > > > > > to list LLDB commits as LLVM-repo commits (at least my commits get
>> > > > > > automatically an LLVM prefix and sometimes get assigned to the LLVM
>> > > > > > repo).
>> > > > > >
>> > > > > > - Raphael
>> > > > > > ___
>> > > > > > lldb-dev mailing list
>> > > > > > lldb-dev@lists.llvm.org
>> > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> > > > > ___
>> > > > > lldb-dev mailing list
>> > > > > lldb-dev@lists.llvm.org
>> > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

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 paranoid firewall, it could be all of them.

I am not sure what would be the right solution here. Not having a
single non-localhost is not good, but neither is annoying firewalls...

pl

(*) If you're looking at the test, the seemingly hardcoded address in
it (10.10.12.3) is not the address the socket binds to, but the
address of the peer we expect to connect to that socket. We open
wildcard sockets when expecting non-local peers.


On Thu, 2 Aug 2018 at 15:28, via lldb-dev  wrote:
>
> 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 tickle the firewall.
>
> Thought I should check in with the experts on what's happening here.
> Thanks,
> --paulr
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Firewall complaint about hosttests.exe

[via lldb-dev]

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 tickle the firewall.

Thought I should check in with the experts on what's happening here.
Thanks,
--paulr

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

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 (getLLDBScriptCommandsFactory) at all,
> > because it's heavily customized for our use case (*), and very
> > different from how typical llvm buildbots are set up. You might be
> > better off setting up a new factory, which just does the typical
> > checkout+build+(optional) test steps, and avoids all of this mess.
>
> OK. For development of these new steps I guess I should run my own buildbot
> master instance? As otherwise that will be probably several/many commits to
> zorg repo (+requested buildbot master restarts) and I may screw up something
> along.

Yes, that would definitely be the best, but last time I tried that, I
couldn't get my master instance to run, for any approximation of the
word "run" (which is part of the reason why I haven't done anything
about this slave factory, even though I really don't like it)..
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

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 not want this, and just want
to set up a buildbot that runs the lldb tests. In that case, this step
is completely unnecessary for you, and can be removed from the config
for your bot. The reason it hasn't been made optional in this slave
factory yet, is that you're the first person except us who wants to
set up a buildbot which runs tests (free/netbsd bots use the same
config too, but they don't run tests).

*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 use case (*), and very
different from how typical llvm buildbots are set up. You might be
better off setting up a new factory, which just does the typical
checkout+build+(optional) test steps, and avoids all of this mess.
Maybe then even the *BSD bots will migrate to that (I tried to warn
them when they started running into the same issues as you are now,
but to no avail). Feel free to ping me on IRC if you want to know more
about this.

(*) some of this is complexity is warranted as the config also
supports running tests on a remote android, but overall, if I was
setting up a fresh bot now, I wouldn't have used this config either.

pl



On Thu, 2 Aug 2018 at 11:11, Jan Kratochvil via lldb-dev
 wrote:
>
> 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 following this guide but various steps are missing there, I will submit
> them after I get it running.
> https://llvm.org/docs/HowToAddABuilder.html
>
> I have done for the last step:
> wget https://storage.googleapis.com/pub/gsutil.tar.gz
> ./setup.py install --user
>
> But maybe it wants also:
> gsutil config
> But I have no idea which Google Cloud Platform Project ID should I enter,
> additionally it even wants from me to pay for Google Cloud Platform.
>
>
> Thanks,
> Jan Kratochvil
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jan Kratochvil via lldb-dev]

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 following this guide but various steps are missing there, I will submit
them after I get it running.
https://llvm.org/docs/HowToAddABuilder.html

I have done for the last step:
wget https://storage.googleapis.com/pub/gsutil.tar.gz
./setup.py install --user

But maybe it wants also:
gsutil config
But I have no idea which Google Cloud Platform Project ID should I enter,
additionally it even wants from me to pay for Google Cloud Platform.


Thanks,
Jan Kratochvil
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev