Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Davide Italiano via lldb-dev]

r316800, thanks!

On Fri, Oct 27, 2017 at 2:07 PM, Zachary Turner  wrote:
> One more nitpick.  Can you make it a dependency of `check-lldb-lit` target
> also?  Just for the sake of pedantry.
>
> On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath  wrote:
>>
>> Ship it.
>>
>> On 27 October 2017 at 13:56, Davide Italiano 
>> wrote:
>> > Take 2 (it can't be in the top-level CMakeList because the check-lldb
>> > target is declared elsewhere).
>> >
>> > $ git diff HEAD
>> > diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
>> > index d5d71d1..958f9f3 100644
>> > --- a/test/CMakeLists.txt
>> > +++ b/test/CMakeLists.txt
>> > @@ -109,6 +109,12 @@ add_python_test_target(check-lldb
>> >"Testing LLDB (parallel execution, with a separate subprocess per
>> > test)"
>> >)
>> >
>> > +# If we're building with an in-tree clang, then list clang as a
>> > dependency
>> > +# to run tests.
>> > +if (TARGET clang)
>> > +  add_dependencies(check-lldb clang)
>> > +endif()
>> > +
>> >  add_custom_target(lldb-test-depends DEPENDS ${LLDB_TEST_DEPENDS})
>> >  # This will add LLDB's test dependencies to the depenednecies for
>> > check-all and
>> >  # include them in the test-depends target.
>> >
>> > On Fri, Oct 27, 2017 at 1:48 PM, Pavel Labath  wrote:
>> >> On 27 October 2017 at 13:28, Zachary Turner  wrote:
>> >>> Maybe make it a dependency of the `check-lldb` target instead of the
>> >>> `lldb`
>> >>> target?
>> >>>
>> >>
>> >> +1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Zachary Turner via lldb-dev]

One more nitpick.  Can you make it a dependency of `check-lldb-lit` target
also?  Just for the sake of pedantry.

On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath  wrote:

> Ship it.
>
> On 27 October 2017 at 13:56, Davide Italiano 
> wrote:
> > Take 2 (it can't be in the top-level CMakeList because the check-lldb
> > target is declared elsewhere).
> >
> > $ git diff HEAD
> > diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
> > index d5d71d1..958f9f3 100644
> > --- a/test/CMakeLists.txt
> > +++ b/test/CMakeLists.txt
> > @@ -109,6 +109,12 @@ add_python_test_target(check-lldb
> >"Testing LLDB (parallel execution, with a separate subprocess per
> test)"
> >)
> >
> > +# If we're building with an in-tree clang, then list clang as a
> dependency
> > +# to run tests.
> > +if (TARGET clang)
> > +  add_dependencies(check-lldb clang)
> > +endif()
> > +
> >  add_custom_target(lldb-test-depends DEPENDS ${LLDB_TEST_DEPENDS})
> >  # This will add LLDB's test dependencies to the depenednecies for
> check-all and
> >  # include them in the test-depends target.
> >
> > On Fri, Oct 27, 2017 at 1:48 PM, Pavel Labath  wrote:
> >> On 27 October 2017 at 13:28, Zachary Turner  wrote:
> >>> Maybe make it a dependency of the `check-lldb` target instead of the
> `lldb`
> >>> target?
> >>>
> >>
> >> +1
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Pavel Labath via lldb-dev]

Ship it.

On 27 October 2017 at 13:56, Davide Italiano  wrote:
> Take 2 (it can't be in the top-level CMakeList because the check-lldb
> target is declared elsewhere).
>
> $ git diff HEAD
> diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
> index d5d71d1..958f9f3 100644
> --- a/test/CMakeLists.txt
> +++ b/test/CMakeLists.txt
> @@ -109,6 +109,12 @@ add_python_test_target(check-lldb
>"Testing LLDB (parallel execution, with a separate subprocess per test)"
>)
>
> +# If we're building with an in-tree clang, then list clang as a dependency
> +# to run tests.
> +if (TARGET clang)
> +  add_dependencies(check-lldb clang)
> +endif()
> +
>  add_custom_target(lldb-test-depends DEPENDS ${LLDB_TEST_DEPENDS})
>  # This will add LLDB's test dependencies to the depenednecies for check-all 
> and
>  # include them in the test-depends target.
>
> On Fri, Oct 27, 2017 at 1:48 PM, Pavel Labath  wrote:
>> On 27 October 2017 at 13:28, Zachary Turner  wrote:
>>> Maybe make it a dependency of the `check-lldb` target instead of the `lldb`
>>> target?
>>>
>>
>> +1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Adding a JSON library to LLVM Support

[Pavel Labath via lldb-dev]

On 27 October 2017 at 13:23, Sam McCall  wrote:
> On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath  wrote:
>>
>> LLDB has a JSON parser/serializer that we'd like to get rid of.
>
> Ah, sorry for missing that!
> What makes you want to get rid of it? Maintenance/duplication, or things you
> don't like about using it?
> Do you see it as a suitable thing to "promote" up to Support for wider use,
> instead?
I don't think the json library in lldb is in a shape that can be
easily promoted to llvm/Support (see previous attempt here
). I think you'd be better off
writing a new one from scratch (or reusing parts of YamlIO).

>
>>
>> The
>> main thing that's missing from YamlIO for us to do that is the ability
>> to handle (or at very least, not choke on) unknown keys (for example,
>> keys that are only generated by an lldb-server from the future --
>> backwards/forwards compatibility).
>
> Interesting - that certainly sounds doable (not knowing the details).
> You'd still need a way to serialize though?

For the lldb <-> lldb-server communication, the ability to ignore the
parts of the message we don't understand would be enough, but I do not
fully understand all the different ways in which it is used. However,
I think that at least in some cases we have a field in a json object,
which is completely opaque to us, but we are expected to take it, and
pass it on to someone. I'm looping in lldb-dev, hopefully someone can
elaborate on the requirements.

>
>>
>> On 27 October 2017 at 12:53, Sam McCall via llvm-dev
>>  wrote:
>> > We don't have a dedicated JSON library in the LLVM tree, I'd like to add
>> > one. The pressing need is for clangd, but we have other tools that
>> > read/write JSON too.
>> >
>> > I'm proposing we write a new one, rather than importing a third-party
>> > library (licensing/integration reasons), on or extending
>> > YamlParser/YamlIO
>> > (usability/flexibility). I lean towards a design that parses a full DOM
>> > at
>> > once, and provides literal-like syntax for composing documents.
>> >
>> > I've written a document laying out the reasons for taking this path, and
>> > my
>> > proposal for a design (with links to a prototype)
>> >
>> > https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
>> > (Comments are enabled, but high-level discussion probably belongs on the
>> > list instead.)
>> >
>> > What do you think? I'm particularly interested in which parts of LLVM
>> > produce/consume JSON (or might want to), and what they need. I'm mostly
>> > familiar with the stuff in clang-tools-extra.
>> >
>> > Cheers, Sam
>> >
>> > ___
>> > LLVM Developers mailing list
>> > llvm-...@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Pavel Labath via lldb-dev]

On 27 October 2017 at 13:28, Zachary Turner  wrote:
> Maybe make it a dependency of the `check-lldb` target instead of the `lldb`
> target?
>

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

Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Davide Italiano via lldb-dev]

Mind if I try to write a patch for this one or you want to do it?

On Fri, Oct 27, 2017 at 12:56 PM, Pavel Labath  wrote:
> Yes, listing clang as a dependency sounds like a good idea.
>
> On 27 October 2017 at 12:45, Davide Italiano  wrote:
>> So, I wiped out my directory for the build and then I created it again using
>> cmake -GNinja ../
>>
>> I found out what the bug/problem is, BTW (was going to reply to this
>> e-mail but you've beaten me to the punch).
>> You switched LLDB to build with an in-tree clang, but ninja check-lldb
>> doesn't really require clang to be built.
>> As such, once I cleaned up my checkout, I ended up typing just `ninja
>> check-lldb` and that failed because clang wasn't built.
>> I claim that `ninja check-lldb` should list clang as dependency when
>> we're running the tests with the in-tree clang.
>> WDYT?
>>
>> Thanks!
>>
>> --
>> Davide
>>
>>
>>
>> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath  wrote:
>>> Did you clean your cmake cache before runinng this? Does
>>> '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
>>> binary you just built?
>>>
>>> On 27 October 2017 at 12:39, Davide Italiano  wrote:
 Yes, it seems `configuration.compiler` is None, so this explodes:

 [...]
 if not is_exe(configuration.compiler):

 [...]

 On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano  
 wrote:
> I think that this change (or some change nearby) broke `check-lldb` on 
> Fedora.
>
> I'm investigating, but in the meanwhile, here's the log.
>
> $ ninja check-lldb
> [2/2] Testing LLDB (parallel execution, with a separate subprocess per 
> test)
> Traceback (most recent call last):
>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
> 7, in 
> lldbsuite.test.run_suite()
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 1099, in run_suite
> parseOptionsAndInitTestdirs()
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 282, in parseOptionsAndInitTestdirs
> if not is_exe(configuration.compiler):
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 54, in is_exe
> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
> st = os.stat(path)
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
> /usr/bin/python2.7
> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64
> --executable /home/davide/work/build-lldb/bin/lldb -s
> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
> ninja: build stopped: subcommand failed.
>
> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
>  wrote:
>> I am going to check in a change (D39215) which causes the check-lldb
>> target to use the just-built clang for compiling the test inferiors
>> (instead of the system compiler, which was the old default). The main
>> reason for this is to provide better reproducibility of test results
>> between different machines/developers, by removing one of the main
>> sources of nondeterminism. This behavior can be overridden by setting
>> the LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
>>
>> For the change to take effect you will need to clean your build folder
>> (or at least, remove the affected variables from your CMakeCache.txt).
>> After this you may observe a change in the test results from the
>> check-lldb run.
>>
>> Note that this change only affect cmake code -- if you run your tests
>> by running dotest.py directly, nothing will change for you.
>>
>> regards,
>> pavel
>> ___
>> 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] check-lldb will start using in-tree clang by default

[Davide Italiano via lldb-dev]

On Fri, Oct 27, 2017 at 12:52 PM, Ted Woodward
 wrote:
> I think if clang exists in-tree, it should be used. If it doesn't, the 
> compiler used to build lldb should be used.
>
> Unless, of course, the compiler is specified with the cmake variables.
>

I think that if the default is to run tests with the clang in-tree,
then clang should be built as dependency.
This kind of matches every other LLVM tool out there (e.g. lld relies
on llvm-mc and objdump and readobj to be built), clang relies on opt
to be built, etc...

Best,

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

Re: [lldb-dev] check-lldb will start using in-tree clang by default

[Pavel Labath via lldb-dev]

Yes, listing clang as a dependency sounds like a good idea.

On 27 October 2017 at 12:45, Davide Italiano  wrote:
> So, I wiped out my directory for the build and then I created it again using
> cmake -GNinja ../
>
> I found out what the bug/problem is, BTW (was going to reply to this
> e-mail but you've beaten me to the punch).
> You switched LLDB to build with an in-tree clang, but ninja check-lldb
> doesn't really require clang to be built.
> As such, once I cleaned up my checkout, I ended up typing just `ninja
> check-lldb` and that failed because clang wasn't built.
> I claim that `ninja check-lldb` should list clang as dependency when
> we're running the tests with the in-tree clang.
> WDYT?
>
> Thanks!
>
> --
> Davide
>
>
>
> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath  wrote:
>> Did you clean your cmake cache before runinng this? Does
>> '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
>> binary you just built?
>>
>> On 27 October 2017 at 12:39, Davide Italiano  wrote:
>>> Yes, it seems `configuration.compiler` is None, so this explodes:
>>>
>>> [...]
>>> if not is_exe(configuration.compiler):
>>>
>>> [...]
>>>
>>> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano  
>>> wrote:
 I think that this change (or some change nearby) broke `check-lldb` on 
 Fedora.

 I'm investigating, but in the meanwhile, here's the log.

 $ ninja check-lldb
 [2/2] Testing LLDB (parallel execution, with a separate subprocess per 
 test)
 Traceback (most recent call last):
   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
 7, in 
 lldbsuite.test.run_suite()
   File 
 "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 1099, in run_suite
 parseOptionsAndInitTestdirs()
   File 
 "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 282, in parseOptionsAndInitTestdirs
 if not is_exe(configuration.compiler):
   File 
 "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 54, in is_exe
 return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
 st = os.stat(path)
 TypeError: coercing to Unicode: need string or buffer, NoneType found
 FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
 /usr/bin/python2.7
 /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64
 --executable /home/davide/work/build-lldb/bin/lldb -s
 /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
 CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
 ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
 ninja: build stopped: subcommand failed.

 On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
  wrote:
> I am going to check in a change (D39215) which causes the check-lldb
> target to use the just-built clang for compiling the test inferiors
> (instead of the system compiler, which was the old default). The main
> reason for this is to provide better reproducibility of test results
> between different machines/developers, by removing one of the main
> sources of nondeterminism. This behavior can be overridden by setting
> the LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
>
> For the change to take effect you will need to clean your build folder
> (or at least, remove the affected variables from your CMakeCache.txt).
> After this you may observe a change in the test results from the
> check-lldb run.
>
> Note that this change only affect cmake code -- if you run your tests
> by running dotest.py directly, nothing will change for you.
>
> regards,
> pavel
> ___
> 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] check-lldb will start using in-tree clang by default

[Ted Woodward via lldb-dev]

I think if clang exists in-tree, it should be used. If it doesn't, the compiler 
used to build lldb should be used.

Unless, of course, the compiler is specified with the cmake variables.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide
> Italiano via lldb-dev
> Sent: Friday, October 27, 2017 2:46 PM
> To: Pavel Labath 
> Cc: LLDB 
> Subject: Re: [lldb-dev] check-lldb will start using in-tree clang by default
> 
> So, I wiped out my directory for the build and then I created it again using
> cmake -GNinja ../
> 
> I found out what the bug/problem is, BTW (was going to reply to this e-mail 
> but
> you've beaten me to the punch).
> You switched LLDB to build with an in-tree clang, but ninja check-lldb doesn't
> really require clang to be built.
> As such, once I cleaned up my checkout, I ended up typing just `ninja 
> check-lldb`
> and that failed because clang wasn't built.
> I claim that `ninja check-lldb` should list clang as dependency when we're
> running the tests with the in-tree clang.
> WDYT?
> 
> Thanks!
> 
> --
> Davide
> 
> 
> 
> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath  wrote:
> > Did you clean your cmake cache before runinng this? Does
> > '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
> > binary you just built?
> >
> > On 27 October 2017 at 12:39, Davide Italiano 
> wrote:
> >> Yes, it seems `configuration.compiler` is None, so this explodes:
> >>
> >> [...]
> >> if not is_exe(configuration.compiler):
> >>
> >> [...]
> >>
> >> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano 
> wrote:
> >>> I think that this change (or some change nearby) broke `check-lldb` on
> Fedora.
> >>>
> >>> I'm investigating, but in the meanwhile, here's the log.
> >>>
> >>> $ ninja check-lldb
> >>> [2/2] Testing LLDB (parallel execution, with a separate subprocess
> >>> per test) Traceback (most recent call last):
> >>>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
> >>> 7, in 
> >>> lldbsuite.test.run_suite()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 1099, in run_suite
> >>> parseOptionsAndInitTestdirs()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py", line 282, in parseOptionsAndInitTestdirs
> >>> if not is_exe(configuration.compiler):
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 54, in is_exe
> >>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
> >>>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
> >>> st = os.stat(path)
> >>> TypeError: coercing to Unicode: need string or buffer, NoneType
> >>> found
> >>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
> >>> /usr/bin/python2.7
> >>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q
> >>> --arch=x86_64 --executable /home/davide/work/build-lldb/bin/lldb -s
> >>> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
> >>> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
> >>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
> >>> ninja: build stopped: subcommand failed.
> >>>
> >>> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
> >>>  wrote:
>  I am going to check in a change (D39215) which causes the
>  check-lldb target to use the just-built clang for compiling the
>  test inferiors (instead of the system compiler, which was the old
>  default). The main reason for this is to provide better
>  reproducibility of test results between different
>  machines/developers, by removing one of the main sources of
>  nondeterminism. This behavior can be overridden by setting the
> LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
> 
>  For the change to take effect you will need to clean your build
>  folder (or at least, remove the affected variables from your
> CMakeCache.txt).
>  After this you may observe a change in the test results from the
>  check-lldb run.
> 
>  Note that this change only affect cmake code -- if you run your
>  tests by running dotest.py directly, nothing will change for you.
> 
>  regards,
>  pavel
>  ___
>  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] check-lldb will start using in-tree clang by default

[Pavel Labath via lldb-dev]

Did you clean your cmake cache before runinng this? Does
'/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
binary you just built?

On 27 October 2017 at 12:39, Davide Italiano  wrote:
> Yes, it seems `configuration.compiler` is None, so this explodes:
>
> [...]
> if not is_exe(configuration.compiler):
>
> [...]
>
> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano  
> wrote:
>> I think that this change (or some change nearby) broke `check-lldb` on 
>> Fedora.
>>
>> I'm investigating, but in the meanwhile, here's the log.
>>
>> $ ninja check-lldb
>> [2/2] Testing LLDB (parallel execution, with a separate subprocess per test)
>> Traceback (most recent call last):
>>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
>> 7, in 
>> lldbsuite.test.run_suite()
>>   File 
>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> line 1099, in run_suite
>> parseOptionsAndInitTestdirs()
>>   File 
>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> line 282, in parseOptionsAndInitTestdirs
>> if not is_exe(configuration.compiler):
>>   File 
>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
>> line 54, in is_exe
>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
>>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
>> st = os.stat(path)
>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
>> /usr/bin/python2.7
>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64
>> --executable /home/davide/work/build-lldb/bin/lldb -s
>> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
>> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
>> ninja: build stopped: subcommand failed.
>>
>> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
>>  wrote:
>>> I am going to check in a change (D39215) which causes the check-lldb
>>> target to use the just-built clang for compiling the test inferiors
>>> (instead of the system compiler, which was the old default). The main
>>> reason for this is to provide better reproducibility of test results
>>> between different machines/developers, by removing one of the main
>>> sources of nondeterminism. This behavior can be overridden by setting
>>> the LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
>>>
>>> For the change to take effect you will need to clean your build folder
>>> (or at least, remove the affected variables from your CMakeCache.txt).
>>> After this you may observe a change in the test results from the
>>> check-lldb run.
>>>
>>> Note that this change only affect cmake code -- if you run your tests
>>> by running dotest.py directly, nothing will change for you.
>>>
>>> regards,
>>> pavel
>>> ___
>>> 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] check-lldb will start using in-tree clang by default

[Davide Italiano via lldb-dev]

Yes, it seems `configuration.compiler` is None, so this explodes:

[...]
if not is_exe(configuration.compiler):

[...]

On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano  wrote:
> I think that this change (or some change nearby) broke `check-lldb` on Fedora.
>
> I'm investigating, but in the meanwhile, here's the log.
>
> $ ninja check-lldb
> [2/2] Testing LLDB (parallel execution, with a separate subprocess per test)
> Traceback (most recent call last):
>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
> 7, in 
> lldbsuite.test.run_suite()
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 1099, in run_suite
> parseOptionsAndInitTestdirs()
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 282, in parseOptionsAndInitTestdirs
> if not is_exe(configuration.compiler):
>   File 
> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 54, in is_exe
> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
> st = os.stat(path)
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
> /usr/bin/python2.7
> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64
> --executable /home/davide/work/build-lldb/bin/lldb -s
> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
> ninja: build stopped: subcommand failed.
>
> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
>  wrote:
>> I am going to check in a change (D39215) which causes the check-lldb
>> target to use the just-built clang for compiling the test inferiors
>> (instead of the system compiler, which was the old default). The main
>> reason for this is to provide better reproducibility of test results
>> between different machines/developers, by removing one of the main
>> sources of nondeterminism. This behavior can be overridden by setting
>> the LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
>>
>> For the change to take effect you will need to clean your build folder
>> (or at least, remove the affected variables from your CMakeCache.txt).
>> After this you may observe a change in the test results from the
>> check-lldb run.
>>
>> Note that this change only affect cmake code -- if you run your tests
>> by running dotest.py directly, nothing will change for you.
>>
>> regards,
>> pavel
>> ___
>> 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] did anyone konw LLDB support lldb + openocd to run dotest.py in bare board like ARM or other non-x86 architecture?

[cui bixiong via lldb-dev]

Hi :

I build a armhf qemu enviroment to test ARM lldb + lldb-server
testsuite.  source code base on LLVM + LLDB + LLD + CLANG formal release
5.0.0.

Target: lldb-server platform --listen *： --server

Host :

(lldb) platform select remote-linux
Platform: remote-linux
Connected: no
(lldb) platform connect connect://0.0.0.0:
Platform: remote-linux
Triple: arm-*-linux-gnueabihf
OS Version: 3.2.0 (3.2.0-4-vexpress)
Kernel: #1 SMP Debian 3.2.51-1
Hostname: debian-armhf.""
Connected: yes
WorkingDir: /root
(lldb) file ./hello.exe
Current executable set to './hello.exe' (arm).
(lldb) log enable gdb-remote packets
(lldb) process launch
history[1] tid=0x6192 <   1> send packet: +
history[2] tid=0x6192 <  19> send packet: $QStartNoAckMode#b0
history[3] tid=0x6192 <   1> read packet: +
history[4] tid=0x6192 <   6> read packet: $OK#9a
history[5] tid=0x6192 <   1> send packet: +
history[6] tid=0x6192 <  13> send packet: $qHostInfo#9b
history[7] tid=0x6192 < 297> read packet:
$triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;distribution_id:64656269616e;watchpoint_exceptions_received:before;endian:little;os_version:3.2.0;os_build:332e322e302d342d7665787072657373;os_kernel:233120534d502044656269616e20332e322e35312d31;hostname:64656269616e2d61726d68662e;#1a
history[8] tid=0x6192 <  18> send packet: $qGetWorkingDir#91
history[9] tid=0x6192 <  14> read packet: $2f726f6f74#a4
history[10] tid=0x6192 <  19> send packet: $qQueryGDBServer#cb
history[11] tid=0x6192 <   7> read packet: $E04#a9
history[12] tid=0x6192 <  73> send packet:
$qModuleInfo:2e2f68656c6c6f2e657865;61726d2d2d6c696e75782d656162696866#b7
history[13] tid=0x6192 <   7> read packet: $E03#a8
history[14] tid=0x6192 <  69> send packet:
$qModuleInfo:6c6962632e736f2e36;61726d2d2d6c696e75782d656162696866#7b
history[15] tid=0x6192 <   7> read packet: $E03#a8
<  36> send packet: $qLaunchGDBServer;host:mtkslt202;#b1
error: unable to launch a GDB server on 'debian-armhf.""'

 i show host and port is uncorrect, is it a bug?


Best Regards
--cuibixiong

On Tue, Oct 24, 2017 at 11:04 PM, Greg Clayton  wrote:

>
> On Oct 24, 2017, at 12:02 AM, cui bixiong  wrote:
>
> Hi
>
> sorry， i'm confuse, in my mind, lldb-server maybe like gdb-server,
> running on Linux-like platform  listening RSP command which send form gdb
> and use ptrace syscall to debug which you want to debug program
>
> is it support remote download to batch mode run all testsuite?
> certainly i think reset baseboard is very important feature too,  but in
> lldb-server maybe not support currently i guess.
>
>
> Yes lldb-server does support a full connection to a remote OS. On
> baseboards you are typically debugging the entire OS so lldb-server won't
> work because you have to OS to run it in the background. Supporting the
> test suite on baseboards will take some effort.
>
>
> Best Regards
> --cuibixiong
>
> On Mon, Oct 23, 2017 at 11:06 PM, Greg Clayton  wrote:
>
>>
>> > On Oct 22, 2017, at 6:21 AM, cuibixiong via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hi
>> >
>> >   did anyone konw LLDB support lldb + openocd to run dotest.py in
>> bare board like ARM or other non-x86 architecture?
>>
>> We run the test suite on iOS devices using the platform stuff. This
>> requires a running lldb-server on the remote system, so we only have the
>> test suite running when we have the lldb-server running in platform mode on
>> the other side. For this to work with baseboards, we would need the JTAG
>> box to respond to many GDB remote protocol packets that "lldb-server
>> platform" implements. I am sure for baseboards the test suite would need to
>> be modified. A few ideas there:
>> - Have the test suite watch for a triple with no os (like
>> "arm64-none-none") and have it go into a baseboard mode
>> - Many tests that might rely on writing to files, reading from files for
>> stdin, and others, would need to be skipped in this mode
>> - Any tests that build and debug shared libraries would either need to be
>> modified to build multiple static binaries or skipped
>> - We might need to make a Bareboard platform and would load the ELF files
>> into memory instead of copying them over like the current platforms do
>>
>> So there would be quite a lot of modifications required to get the test
>> suite running. We will be happy to help you if you choose to try this.
>>
>> Greg Clayton
>>
>> >
>> > Best Regards
>> > —cuibixiong
>> > ___
>> > 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