Re: [lldb-dev] [3.8 Release] Release status
On Thu, Feb 18, 2016 at 4:22 PM, Hans Wennborg wrote: > According to the schedule (e.g. on the right on llvm.org), we should > have tagged the release by now, but we haven't, so we're officially > behind schedule. I'm still optimistic that we can wrap this up pretty > soon, though. > > This is what's blocking us: > > - PR26509: Crash in InnerLoopVectorizer::vectorizeLoop() > I'm waiting to hear what Cong comes up with, otherwise we can revert > r255691 on the branch > > - Shrink-wrapping vs TLS: Davide and Quentin are working on it > http://reviews.llvm.org/D17427 -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On Thu, Feb 16, 2017 at 10:16 PM, Mehdi Amini via llvm-dev wrote: > Hello all, > > GSOC is around the corner, and the LLVM projects plans to participate again > this year. For those who don’t know about GSOC, students are proposing a > project that they will work on for 3 months. Amongst other, one goal for > LLVM is to mentor students to become good developers and also contributors > to the LLVM project (or user/advocate of LLVM for building other cool > projects). > > A key part of the process is about how do we select the projects. The way > we’ve done it last year, is that the volunteer mentors shared an email > thread and ultimately each one individually ranked the projects. We kept the > average grading for each project to ranked them overall. > > In order to make the process more transparent to student applicants, we want > to formalize and announce the criteria for ranking and selection project. > > The purpose of this email is to gather community feedback about the > criterion that mentors should apply when ranking projects, for example: > > - Should we favor a student which has past contributions to LLVM compared to > a newcomer? Is it more important or as equally important as the quality of > the proposal? I really think that past contributions are *very* important and *a big plus*. When I was involved in FreeBSD we ended up with people submitting high-quality proposals, got accepted and then we realized at day 1 of coding they didn't even set up a VM or knew how to build things. In other words, I'm under the impression that students need to be well aware of the development workflow and being able to show up some involvement in the community. > - How should we rank (if any) “research or unbounded projects” vs “project > with an immediate application”? Should we strive to keep a balance? Again, my opinion, but we should give high(er) priority to projects which can produce something reasonable in 3 months. If it's a research project, it's fine, but I think there should be a bound (e.g. tune the thresholds for unrolling). > - What about “projects that touch LLVM/Clang/…” vs “projects that are > building something on top of LLVM”? (For example this project was first > proposed to be selected by LLVM before being rejected and finally picked by > the Julia project directly: > https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ > )? > - Should we ask that the work is done upstream all along? In the past there > have been project developed on GitHub outside the community that have never > been merged. The LLVM developer policy has a full section insisting on > incremental development ( > http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). > Yes, I think incremental patches are the way to go. If there are bugfixes, etc.. they should be merged immediately (after code review). If it's a larger chunk of work it should be in a state where others can take over if the student stops being interested after the summer (or we want to remove the thing altogether, e.g. a pass). > Hopefully we should be able to provide a set of guidelines to student that > would help them fill the best application, and avoid unfortunate surprise at > the end of the process. > > We should have this discussion before receiving the projects proposals, > which opens on 2/28. > -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ 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
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
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
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
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
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
I'm testing with the following change.
Should I shove the dependency instead in test/CmakeLists.txt ?
$ git diff HEAD
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c6b082e..b6d24f8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,6 +65,7 @@ if(LLDB_INCLUDE_TESTS)
if (TARGET clang)
set(LLDB_DEFAULT_TEST_C_COMPILER
"${LLVM_BINARY_DIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
set(LLDB_DEFAULT_TEST_CXX_COMPILER
"${LLVM_BINARY_DIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
+add_dependencies(lldb clang)
else()
set(LLDB_DEFAULT_TEST_C_COMPILER "")
set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
Thanks!
--
Davide
On Fri, Oct 27, 2017 at 1:16 PM, Zachary Turner wrote:
> Agree we should just build clang as a dependency. We're already building
> most of it anyway since we require it for the expression parser, so spitting
> out the executabatle as well should not be too controversial.
>
> On Fri, Oct 27, 2017 at 12:58 PM Davide Italiano via lldb-dev
> wrote:
>>
>> 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
>> >>>&
Re: [lldb-dev] check-lldb will start using in-tree clang by default
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
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] lldb test suite on macOS 10.13 (High Sierra)
Pavel, I happened to hit this. I'm not sure how you worked around, as I tried to export SDKROOT=macosx but that didn't work for me. Do you have a patch or a series of commands I can run? Thanks, -- Davide On Thu, Nov 16, 2017 at 4:25 AM, Pavel Labath via lldb-dev wrote: > Right, after learning way more than I ever wanted to know about xcrun, > I think I see the issue. When running with empty SDKROOT variable, > xcrun sets SDKROOT to "/" when running clang: > $ SDKROOT= xcrun --no-cache --log --verbose clang > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c > -o > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so > -framework Python -Xlinker -dylib -v > xcrun: note: PATH = '/usr/bin:/bin' > xcrun: note: SDKROOT = '/' > ^ WRONG. there are no > python headers there > > . > > env SDKROOT=/ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c > -o > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so > -framework Python -Xlinker -dylib -v > > ... > > #include "..." search starts here: > #include <...> search starts here: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > /usr/include > /System/Library/Frameworks (framework directory) > /Library/Frameworks (framework directory) > clang gets the include path wrong > > End of search list. > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10: > fatal error: 'Python/Python.h' file not found > #include > ^ > 1 error generated. > ^ and errors out > > > > On the other hand, if I invoke xcrun with SDKROOT=macosx, everything > works just fine: > > $ SDKROOT=macosx xcrun --no-cache --log --verbose clang > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c > -o > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so > -framework Python -Xlinker -dylib -v > xcrun: note: looking up SDK with > '/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk > macosx -version Path' > xcrun: note: PATH = '/usr/bin:/bin' > xcrun: note: SDKROOT = 'macosx' > xcrun: note: TOOLCHAINS = '' > xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer' > xcrun: note: XCODE_DEVELOPER_USR_PATH = '' > xcrun: note: xcrun_db = > '/var/folders/bt/tws6gynx0ws1cc4ss53_pvqmgq/T/xcrun_db' > xcrun: note: lookup resolved to: > '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk' > xcrun: note: PATH = '/usr/bin:/bin' > xcrun: note: SDKROOT = > '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk' > ^^ correct. a valid SDK is located there > > ... > > env > SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c > -o > /Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so > -framework Python -Xlinker -dylib -v > > ... > > #include "..." search starts here: > #include <...> search starts here: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks > (framework directory) > > ^ include path is good and compilation succeeds > > > I've checked this on 10.12 and the xcrun behavior is same there (with > the difference that 10.12 does contain headers in > /System/Library/Frameworks. > > It seems we could fix this by changing the invocation in dotest to > explicitly request SDKROOT=macosx. As far, as I can tell, this would > only break if someone tried to run dotest with iOS as host, but I > don't think that's ever going to be supported(?) > > What do you think? > > > On 15 November 2017 at 20:25, Jim Ingham wrote: >> The build should be finding the version in the SDK within Xcode. I do have >> the CommandLineTools directory on my system, but it doesn’t have an SDK >> directory in it. I wonder if that is causing
Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)
Jason probably knows about the crash hook. On Tue, Dec 19, 2017 at 4:24 AM, Pavel Labath wrote: > On 18 December 2017 at 23:51, Adrian Prantl wrote: >> I also just hit this and apparently this is an intentional behavior of xcrun. >> >> Note that this only affects systems that have the so-called command line >> tools installed (this is what you get when you install the command line >> tools without installing Xcode). >> >> When the command line tools are installed *and* xcrun is run without >> explicitly asking for an sdk, it will add /usr/local/include to the search >> path instead of adding the -isysroot >> /Applications/Xcode.app/.../MacOSX10.13.sdk that we want here. This explains >> why Pavel's workaround works. >> >> I'm not yet sure whether requiring the macosx SDK in this file is always the >> right thing to do here or if there is a better solution. >> > > Setting SDKROOT=macosx is not ideal, but I think it should fine. This > is building host code, so the only case where this would be wrong is > if someone tried to run dotest on an iOS (WatchOS, ...) host, which I > think you guys don't do. > > TBH, I would even consider removing the "crash hook" altogether. Is > anyone using this functionality on your side? The feature sounds like > it would be useful in the old dotest days, when all tests were run > sequentially in a single process, but now we run pretty much every > test in it's own process, so it doesn't look like it should be a > problem figuring out what the test was doing when it crashed. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability
On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev wrote: > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test directories and this prompted me to > ask a couple of general noob questions about the LLDB testsuite. > > My understanding is that all execution tests are compiled using using `make` > in-tree. I.e.: the test driver (dotest.py) effectively executes something > equivalent to `cd $srcdir/packages/.../mytest && make`. And it does this in a > serial fashion for all configurations (dwarf, dSYM, dwo, ...) and relies on > the `clean` target to be implemented correctly. > > I don't understand all the design decisions that went into the LLDB > testsuite, but my naive intuition tells me that this is sub-optimal (because > of the serialization of the configurations) and dangerous (because it relies > on make clean being implemented correctly). It seems to me that a better > approach would be to create a separate build directory for each test variant > and then invoke something like `cd $builddir/test/mytest.dwarf && make -C > $srcdir/packages/.../mytest`. This way all configurations can build in > parallel, and we can simply nuke the build directory afterwards and this way > get rid of all custom implementations of the `clean` target. > I think this is a much better strategy. FWIW, I wouldn't object if you want to switch to cmake entirely as LLVM is using it as its only true build system, but that seems a much larger change. In any case, whatever gets decided, happy to help you with that. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability
On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev wrote: > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test directories and this prompted me to > ask a couple of general noob questions about the LLDB testsuite. > > My understanding is that all execution tests are compiled using using `make` > in-tree. I.e.: the test driver (dotest.py) effectively executes something > equivalent to `cd $srcdir/packages/.../mytest && make`. And it does this in a > serial fashion for all configurations (dwarf, dSYM, dwo, ...) and relies on > the `clean` target to be implemented correctly. > > I don't understand all the design decisions that went into the LLDB > testsuite, but my naive intuition tells me that this is sub-optimal (because > of the serialization of the configurations) and dangerous (because it relies > on make clean being implemented correctly). It seems to me that a better > approach would be to create a separate build directory for each test variant > and then invoke something like `cd $builddir/test/mytest.dwarf && make -C > $srcdir/packages/.../mytest`. This way all configurations can build in > parallel, and we can simply nuke the build directory afterwards and this way > get rid of all custom implementations of the `clean` target. > > - Is this already possible, and/or am I misunderstanding how it works? > - Would this be a goal that is worthwhile to pursue? > - Is there a good reason why we are not already doing it this way? > As we're discussing lldb test suite changes, another detail that I find a little weird is that every time you execute the test suite you get a new build directory named after the time at which you run the test. It would be much much better IMHO to just have a `log/` generic directory where the failures are logged, and those who want to override this setting can just pass a flag. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability
On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano wrote: > On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev > wrote: >> Hi lldb-dev! >> >> I've been investigating some spurious LLDB test suite failures on >> http://green.lab.llvm.org/green/ that had to do with build artifacts from >> previous runs lying around in the test directories and this prompted me to >> ask a couple of general noob questions about the LLDB testsuite. >> >> My understanding is that all execution tests are compiled using using `make` >> in-tree. I.e.: the test driver (dotest.py) effectively executes something >> equivalent to `cd $srcdir/packages/.../mytest && make`. And it does this in >> a serial fashion for all configurations (dwarf, dSYM, dwo, ...) and relies >> on the `clean` target to be implemented correctly. >> >> I don't understand all the design decisions that went into the LLDB >> testsuite, but my naive intuition tells me that this is sub-optimal (because >> of the serialization of the configurations) and dangerous (because it relies >> on make clean being implemented correctly). It seems to me that a better >> approach would be to create a separate build directory for each test variant >> and then invoke something like `cd $builddir/test/mytest.dwarf && make -C >> $srcdir/packages/.../mytest`. This way all configurations can build in >> parallel, and we can simply nuke the build directory afterwards and this way >> get rid of all custom implementations of the `clean` target. >> >> - Is this already possible, and/or am I misunderstanding how it works? >> - Would this be a goal that is worthwhile to pursue? >> - Is there a good reason why we are not already doing it this way? >> > > As we're discussing lldb test suite changes, another detail that I > find a little weird is that every time you execute the test suite you > get a new build directory named after the time at which you run the > test. > It would be much much better IMHO to just have a `log/` generic > directory where the failures are logged, and those who want to > override this setting can just pass a flag. > (The logs should also be moved out of tree, FWIW). -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Anybody using the Go/Java debugger plugins?
Hi, during my wandering I stumbled upon the `Go` and the `Java` plugins in the lldb source tree. They seem to not have been touched in a while, and I'm not necessarily sure they're in a working state. Keeping them in tree is a maintenance burden, so unless somebody is actively using them or somebody is willing to step up as maintainers, I'm not necessarily sure we should pay this price. An alternative would be that of having a pluggable mechanism to add language support (I haven't fleshed out the details of this yet, but it should be possible, somehow). Other languages which have out of tree support might benefit from this (e.g. Swift/Rust). Thoughts? -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols
On Fri, Jan 26, 2018 at 8:38 AM, Erik Pilkington via lldb-dev wrote: > > > On 2018-01-25 1:58 PM, Greg Clayton wrote: >>> >>> On Jan 25, 2018, at 10:25 AM, Erik Pilkington >>> wrote: >>> >>> Hi, >>> I'm not at all familiar with LLDB, but I've been doing some work on the >>> demangler in libcxxabi. It's still a work in progress and I haven't yet >>> copied the changes over to ItaniumDemangle, which AFAIK is what lldb uses. >>> The demangler in libcxxabi now demangles the symbol you attached in 3.31 >>> seconds, instead of 223.54 on my machine. I posted a RFC on my work here >>> (http://lists.llvm.org/pipermail/llvm-dev/2017-June/114448.html), but >>> basically the new demangler just produces an AST then traverses it to print >>> the demangled name. >> >> Great to hear the huge speedup in demangling! LLDB actually has two >> demanglers: a fast one that can demangle 99% of names, and we fall back to >> ItaniumDemangle which can do all names but is really slow. It would be fun >> to compare your new demangler with the fast one and see if we can get rid of >> the fast demangler now. >>> >>> >>> I think a good way of making this even faster is to have LLDB consume the >>> AST the demangler produces directly. The AST is a better representation of >>> the information that LLDB wants, and finishing the demangle and then fishing >>> out that information from the output string is unfortunate. From the AST, it >>> would be really straightforward to just individually print all the >>> components of the name that LLDB wants. >> >> This would help us to grab the important bits out of the mangled name as >> well. We chop up a demangled name to find the base name (string for >> std::string), containing context (std:: for std::string) and we check if we >> can tell if the function is a method (look for trailing "const" modifier on >> the function) versus a top level function (since the mangling doesn't fully >> specify what is a namespace and what is a class (like in "foo::bar::baz()" >> we don't know if "foo" or "bar" are classes or namespaces. So the AST would >> be great as long as it is fast. >> >>> Most of the time it takes to demangle these "symbols from hell" is during >>> the printing, after the AST has been parsed, because the demangler has to >>> flatten out all the potentially nested back references. Just parsing to an >>> AST should be about proportional to the strlen of the mangled name. Since >>> (AFAIK) LLDB doesn't use some sections of the demangled name often (such as >>> parameters), from the AST LLDB could lazily decide not to even bother fully >>> demangling some sections of the name, then if it ever needs them it could >>> parse a new AST and get them from there. I think this would largely fix the >>> issue, as most of the time these crazy expansions don't occur in the name >>> itself, but in the parameters or return type. Even when they do appear in >>> the name, it would be possible to do some simple name classification (ie, >>> does this symbol refer to a function) or pull out the basename quickly >>> without expanding anything at all. >>> >>> Any thoughts? I'm really not at all familiar with LLDB, so I could have >>> this all wrong! >> >> AST sounds great. We can put this into the class we use to chop us C++ >> names as that is really our goal. >> >> So it would be great to do a speed comparison between our fast demangler >> in LLDB (in FastDemangle.cpp/.h) and your updated libcxxabi version. If >> yours is faster, remove FastDemangle and then update the >> llvm::ItaniumDemangle() to use your new code. >> >> ASTs would be great for the C++ name parser, >> >> Let us know what you are thinking, > > > Hi Greg, > > I'll almost finished with my work on the demangler, hopefully I'll be done > within a few weeks. Once that's all finished I'll look into exporting the > AST and comparing it to FastDemangle. I was thinking about adding a version > of llvm::itaniumMangle() that returns a opaque handle to the AST and > defining some functions on the LLVM side that take that handle and return > some extra information. I'd be happy to help out with the LLDB side of > things too, although it might be better if someone more experienced with > LLDB did this. > That's great to hear. Not having 3 different demanglers scattered between lldb and llvm will be a big win for everybody. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
I agree. I plan to remove the two backends (well, at least submit requests for) in 3 weeks from today. There are a lot of moving pieces right now and I'd really love for things to stabilize but also give people an opportunity to speak up, if they want to. -- Davide On Tue, Jan 30, 2018 at 5:30 AM, Tamas Berghammer wrote: > Originally I added the Java support to work with the Android ART runtime and > it has some pretty hard beaked in dependencies on the debug info ART > generates and on the version of ART available at that time (Android N) even > though I don't think this limitation is communicated clearly in source code > or in code reviews. Considering that AFAIK it haven't been tested with > Android O and haven't seen any bugfix for a while I would assume it is > mostly unused so I am happy to get it removed. And as Pavel said if somebody > want to use it again we can always add it back in with a better testing > strategy and long term plan. > > Generally for new language support I think we should have a similar policy > then what LLVM have for new backends. They should be developed out of tree > first without us providing a stable API (developer can fork a specific > version of LLDB, preferably upstream language independent bugfixes and then > pull in new changes once in a while) and if they are mature enough both in > terms of testing and maintenance commitment then they can be pulled into the > main LLDB source tree. > > Tamas > > On Tue, Jan 30, 2018 at 11:52 AM Pavel Labath via lldb-dev > wrote: >> >> Right, so, independently of this thread here, we've had an internal >> discussion about reviving java support. However, it is still very >> uncertain that this will actually happen , so I'm not opposed to >> removing it as we can always add it back later (with better testing, >> hopefully). >> >> Regardless of what happens here (and in light of the rust thread), I >> think a clearer bar for what we expect from new language support >> plugin would be useful for everyone. >> >> pl >> >> On 22 January 2018 at 20:13, Jim Ingham wrote: >> > To Davide's alternative: LLDB does handle loading plugins that use the >> > SB API's (for things like data formatters.) But there's not currently an >> > SB >> > interface to support >> > writing a full language plugin, and we don't export the lldb_private >> > API's from the lldb binary. So there's no current mechanism to provide >> > out-of-tree language plugins. It would be great to enable out-of-tree >> > language support mechanisms but we would have to design an SB interface for >> > that purpose. >> > >> > I see occasional questions about using Go with lldb on stack overflow >> > and the like. It might be good to put out a more general "anybody >> > interested in supporting this" call for Go, but I'm not sure the lldb-dev >> > list is the best place to find an owner. Is there some Go dev list we can >> > ask to see if anybody cares to support this? >> > >> > Non-stop never actually worked, it was just a promise, and the code for >> > it was pretty thin. I would be okay with pulling that out unless somebody >> > is actually getting good use out of it. >> > >> > Jim >> > >> >> On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev >> >> wrote: >> >> >> >> The Go support for added by Ryan as a 20% project. Now that he's no >> >> longer working for Google, it's pretty much abandoned. >> >> The Java support was added by us (android folks) to support java >> >> debugging (to a certain extent). However, we never really finished the >> >> project, so we're not using that code now. We're hoping to come back >> >> to it one day, but I agree we should not burden everyone else while we >> >> make up our mind on that. >> >> >> >> So I don't think anybody would shout at us if we removed them right >> >> now, but maybe we should make some effort to find a maintainer for >> >> them before removal? E.g. publicly declare that they are going to be >> >> deleted on date unless a maintainer steps up to take care of them >> >> (we can define the minimum level of support we'd expect from such a >> >> maintainer). Then I can e.g. forward the email to the Google Go folks >> >> and see if anyone of them wants to take that up. >> >> >> >> As for Java, I'm going to bring up the desire to remove the Java >> >> plugin on our team's meeting this week and get back to you with the >> >> result. >> >> >> >> >> >> In general I think that a clear deprecation/removal process would be >> >> nice to have. I have a couple of things I think are broken/unused >> >> (PlatformKalimba? non-stop mode?) but I haven't brought them up >> >> because I was unsure how to handle it. >> >> >> >> >> >> On 22 January 2018 at 15:28, Davide Italiano >> >> wrote: >> >>> Hi, >> >>> during my wandering I stumbled upon the `Go` and the `Java` plugins in >> >>> the lldb source tree. >> >>> They seem to not have been touched in a while, and I'm not necessarily >> >>> sure they're in a working state. Keeping the
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
On Thu, Feb 1, 2018 at 6:50 AM, Pavel Labath wrote: > On 30 January 2018 at 23:21, Davide Italiano wrote: >> I agree. > > Just to check: Does that apply to Tamas's paragraph below, as in > that's the guidelines we should be giving to new language plugin > implementors? > Yes, that's what I meant. > If that's the case, then I agree as well, although I think we should > be a bit more clean on the details (e.g. does a test that runs only if > the developer has a specific version of the language X's compiler > installed count?) > > >> I plan to remove the two backends (well, at least submit requests for) >> in 3 weeks from today. > > BTW, what made you skip OCaml? :P Nothing, I just didn't notice we had support for it :) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [RFC] Testsuite in lldb & possible future directions
Hi, in the last couple of months a lot of people put a lot of attentions and energy into lldb and we're starting to see the first results. I decided to sit down and write this e-mail to state where we are and what are some possible future directions for the projects, in terms of better quality/higher testability. Current state: 1) We got the testsuite on MacOS to build with zero unexpected successes and zero failures (modulo one change I'm going to push tomorrow). This is a collaborative effort and it's very important because it allows us to push for unexpected successes as failures on the bots, allowing us to discover issues quicker. Other platform I think are improving their state as well, mainly thanks to the work of Pavel and Jan. 2) Adrian is pushing some changes that will allow us to build tests out of tree. This is particularly good because it doesn't matter the build directly and indirectly makes the testsuite more reliable as you can just wipe the build directory when you're done and retry. It also opens the path for new improvements, e.g. sharing a module cache across all tests instead of creating a module cache per-test. 3) Vedant spent a lot of time fixing modules issues & ubsan/asan failures, which. again, improved reliability. Future: 1) I'm currently exploring ways of testing more akin to what llvm does. We already have a bunch of unit tests, and I'm considering to leverage `lldb-test` to experiment testing parts of the compilers that don't really need interactivity (e.g. expression parsing/autocomplete). I'm not sure whether this will lead to anything, but if we can make the process easier for developers coming from other bits of LLVM, I think we should (at least we should give it a try). 2) Now that we raised the quality of our standards (we've been with green bots for a while), I'd love to keep some time and focus on the standards for future commits. I think we should adhere to the LLVM policy here https://llvm.org/docs/DeveloperPolicy.html#quality So, commits that break tests/break the build/don't include a test might be reverted. In addition, commits with design decisions not previously discussed might be reverted if there are concerns about the general direction. 3) In the short term I plan to remove support for unmaintained languages (Java/Go/Swift). This allows us to bring them back again (or bring new languages) but have a better plan for testability & maintainability. I'm pretty sure other people have ideas on what they're working on/want to push/do next, so I'll let them speak. Conclusions: The reliability of the suite (and the health of the codebase) is very important to us. If you have issues, let us know. In general, I'm looking for any kind of feedback, feel free to speak! Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy into lldb and we're starting to see the first results. I >> decided to sit down and write this e-mail to state where we are and >> what are some possible future directions for the projects, in terms of >> better quality/higher testability. >> >> Current state: >> >> 1) We got the testsuite on MacOS to build with zero unexpected >> successes and zero failures (modulo one change I'm going to push >> tomorrow). This is a collaborative effort and it's very important >> because it allows us to push for unexpected successes as failures on >> the bots, allowing us to discover issues quicker. Other platform I >> think are improving their state as well, mainly thanks to the work of >> Pavel and Jan. > > I don't mean to belittle this statement, as I think the situation has > definitely improved a lot lately, but I feel I have to point out > that's I've never been able to get a clean test suite run on a mac > (not even the "0 failures" kind of clean). I'm not sure what are these > caused by, but I guess that's because the tests are still very much > dependent on the environment. So, I have to ask: what kind of > environment are you running those tests in? > > My machine is not a completely off-the-shelf mac, as it has some > google-specific customizations. I don't really know what this > encompasses, but I would be surprised if these impact the result of > the test suite. If I had to bet, my money would be on your machines > having some apple-specific stuff which is not available in regular > macs. > > I tried an experiment today. I configured with: cmake ../../llvm > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -GNinja. First > problem I ran into was that I couldn't run check-lldb, as the clang I > have just built was unable to compile any of the test binaries due to > missing headers (this could be a manifestation of the SDKROOT issue we > ran into a couple of weeks ago). So, I tried running with the system > compiler and I got this output: > > FAIL: test_c_global_variables_dwarf > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_c_global_variables_gmodules > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_dsym (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_dwarf (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_gmodules (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_with_python_api_dsym (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_dwarf > (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_gmodules > (lang/cpp/class_static/TestStaticVariables.py) > ERROR: test_debug_info_for_apple_types_dsym > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_dwarf > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_gmodules > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > UNEXPECTED SUCCESS: test_lldbmi_output_grammar > (tools/lldb-mi/syntax/TestMiSyntax.py) > UNEXPECTED SUCCESS: test_process_interrupt_dsym > (functionalities/thread/state/TestThreadStates.py) > UNEXPECTED SUCCESS: test_process_interrupt_gmodules > (functionalities/thread/state/TestThreadStates.py) > > So, I guess my question is: are you guys looking into making sure that > others are also able to reproduce the 0-fail+0-xpass state? I would > love to run the mac test suite locally, as I tend to touch a lot of > stuff that impacts all targets, but as it stands now, I have very > little confidence that the test I am running reflect in any way the > results you will get when you run the test on your end. > > I am ready to supply any test logs or information you need if you want > to try to tackle this. > Yes, I'm definitely interested in making the testusuite working/reliable on any configuration. I was afraid there were a lot of latent issues, that's why I sent this mail in the first place. It's also the reason why I started thinking about `lldb-test` as a driver for testing, because I found out the testsuite being a little inconsistent/brittle depending on the environment it's run on (which, FWIW, doesn't happen when you run lit/FileCheck or even the unit tests in lldb). I'm not currently claiming switching to a different method would improve the situation, but it's worth a shot. >> 3) In the short term I plan to remove support for unmaintained >> languages (Java/Go/Swift). This allows us to bring them back again (or > I hope you meant OCaml instead of Swift. :P Oh, yes, sigh. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: > On 6 February 2018 at 04:11, Davide Italiano via lldb-dev > wrote: >> Hi, >> in the last couple of months a lot of people put a lot of attentions >> and energy into lldb and we're starting to see the first results. I >> decided to sit down and write this e-mail to state where we are and >> what are some possible future directions for the projects, in terms of >> better quality/higher testability. >> >> Current state: >> >> 1) We got the testsuite on MacOS to build with zero unexpected >> successes and zero failures (modulo one change I'm going to push >> tomorrow). This is a collaborative effort and it's very important >> because it allows us to push for unexpected successes as failures on >> the bots, allowing us to discover issues quicker. Other platform I >> think are improving their state as well, mainly thanks to the work of >> Pavel and Jan. > > I don't mean to belittle this statement, as I think the situation has > definitely improved a lot lately, but I feel I have to point out > that's I've never been able to get a clean test suite run on a mac > (not even the "0 failures" kind of clean). I'm not sure what are these > caused by, but I guess that's because the tests are still very much > dependent on the environment. So, I have to ask: what kind of > environment are you running those tests in? > > My machine is not a completely off-the-shelf mac, as it has some > google-specific customizations. I don't really know what this > encompasses, but I would be surprised if these impact the result of > the test suite. If I had to bet, my money would be on your machines > having some apple-specific stuff which is not available in regular > macs. > > I tried an experiment today. I configured with: cmake ../../llvm > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -GNinja. First > problem I ran into was that I couldn't run check-lldb, as the clang I > have just built was unable to compile any of the test binaries due to > missing headers (this could be a manifestation of the SDKROOT issue we > ran into a couple of weeks ago). So, I tried running with the system > compiler and I got this output: > > FAIL: test_c_global_variables_dwarf > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_c_global_variables_gmodules > (lang/c/global_variables/TestGlobalVariables.py) > FAIL: test_dsym (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_dwarf (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_gmodules (functionalities/ubsan/basic/TestUbsanBasic.py) > FAIL: test_with_python_api_dsym (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_dwarf > (lang/cpp/class_static/TestStaticVariables.py) > FAIL: test_with_python_api_gmodules > (lang/cpp/class_static/TestStaticVariables.py) > ERROR: test_debug_info_for_apple_types_dsym > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_dwarf > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > ERROR: test_debug_info_for_apple_types_gmodules > (macosx/debug-info/apple_types/TestAppleTypesIsProduced.py) > UNEXPECTED SUCCESS: test_lldbmi_output_grammar > (tools/lldb-mi/syntax/TestMiSyntax.py) > UNEXPECTED SUCCESS: test_process_interrupt_dsym > (functionalities/thread/state/TestThreadStates.py) > UNEXPECTED SUCCESS: test_process_interrupt_gmodules > (functionalities/thread/state/TestThreadStates.py) > FWIW, I strongly believe we should all agree on a configuration to run tests and standardize on that. It's unfortunate that we have two build systems, but there are plans to move away from manually generating xcodebuild, as many agree it's a terrible maintenance burden. So, FWIW, I'll share my conf (I'm on high Sierra): git clone https://github.com/monorepo symlink clang -> tools symlink lldb -> tools symlink libcxx -> projects (this particular one has caused lots of trouble for me in the past, and I realized it's undocumented :() cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm ninja check-lldb This *should* work just fine for every developer (and we should error out if all the dependencies are not in place). If it doesn't, well, it's a bug. Can you please try with this and report all the bugs that you find? I'll work with you to fix them, as I'm particularly interested in getting the lldb experience for users flawlessly out-the-box (at least on the platforms I work on :) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Tue, Feb 6, 2018 at 8:18 AM, Pavel Labath wrote: > On 6 February 2018 at 15:41, Davide Italiano wrote: >> On Tue, Feb 6, 2018 at 7:09 AM, Pavel Labath wrote: >>> On 6 February 2018 at 04:11, Davide Italiano via lldb-dev >>> >>> So, I guess my question is: are you guys looking into making sure that >>> others are also able to reproduce the 0-fail+0-xpass state? I would >>> love to run the mac test suite locally, as I tend to touch a lot of >>> stuff that impacts all targets, but as it stands now, I have very >>> little confidence that the test I am running reflect in any way the >>> results you will get when you run the test on your end. >>> >>> I am ready to supply any test logs or information you need if you want >>> to try to tackle this. >>> >> >> Yes, I'm definitely interested in making the testusuite >> working/reliable on any configuration. >> I was afraid there were a lot of latent issues, that's why I sent this >> mail in the first place. >> It's also the reason why I started thinking about `lldb-test` as a >> driver for testing, because I found out the testsuite being a little >> inconsistent/brittle depending on the environment it's run on (which, >> FWIW, doesn't happen when you run lit/FileCheck or even the unit tests >> in lldb). I'm not currently claiming switching to a different method >> would improve the situation, but it's worth a shot. >> > > Despite Zachary's claims, I do not believe this is caused by the test > driver (dotest). It's definitely not beautiful, but I haven't seen an > issue that would be caused by this in a long time. The issue is that > the tests are doing too much -- even the simplest involves compiling a > fully working executable, which pulls in a lot of stuff from the > environment (runtime libraries, dynamic linker, ...) that we have no > control of. And of course it makes it impossible to test the debugging > functionality of any other platform than what you currently have in > front of you. > > In this sense, the current setup makes an excellent integration test > suite -- if you run the tests and they pass, you can be fairly > confident that the debugging on your system is setup correctly. > However, it makes a very bad regression test suite, as the tests will > be checking something different on each machine. > Yes, I didn't complain about "dotest" in general, but, as you say, the fact that it pull in lots of stuffs we don't really have control on. Also, most of the times I actually found out we've been sloppy watching bots for a while, or XFAILING tests instead of fixing them and that resulted in issues piling up). This is a more general problem not necessarily tied to `dotest` as a driver. > So I believe we need more lightweight tests, and lldb-test can provide > us with that. The main question for me (and that's something I don't +1. > really have an answer to) is how to make writing tests like that easy. > E.g. for these "foreign" language plugins, the only way to make a > self-contained regression test would be to check-in some dwarf which > mimics what the compiler in question would produce. But doing that is > extremely tedious as we don't have any tooling for that. Since debug > info is very central to what we do, having something like that would > go a long way towards improving the testing situation, and it would be > useful for C/C++ as well, as we generally need to make sure that we > work with a wide range of compiler versions, not just accept what ToT > clang happens to produce. > I think the plan here (and I'd love to spend some time on this once we have stability, which seems we're slowly getting) is that of enhancing `yaml2*` to do the work for us. I do agree is a major undertaken but even spending a month on it will go a long way IMHO. I will try to come up with a plan after discussing with folks in my team (I'd really love to get also inputs from DWARF people in llvm, e.g. Eric or David Blake). > > PS: I saw your second email as well. I'm going to try out what you > propose, most likely tomorrow. Thanks! -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath wrote: > On 7 February 2018 at 14:20, Zachary Turner wrote: >> >> As someone who gave up on trying to set up a bot due to flakiness, I have a >> different experience. > > I did not say it was easy to get to the present point, and I am > certain that the situation is much harder on windows. But I believe > this is due to reasons not related to the test runner (such various > posixism spread out over the codebase and the fact that windows uses a > completely different (i.e. lest tested) code path for debugging). > > FWIW, we also have a windows bot running remote tests targetting > android. It's not as stable as the one hosted on linux, but most of > the issues I've seen there also do not point towards dotest. > >> Rust is based on llvm so we have the tools necessary for that. The rest are >> still maybe and someday so we can cross that bridge when (if) we come to it > > I don't know enough about Rust to say whether that is true. If it uses > llvm as a backend then I guess we could check-in some rust-generated > IR to serve as a test case (but we still figure out what exactly to do > with it). > > However, I would assert that even for C family languages a more > low-level approach than "$CC -g" for generating debug info would be > useful. People generally will not have their compiler and debugger > versions in sync, so we need tests that check we handle debug info > produced by older versions of clang (or gcc for that matter). And > then, there are the tests to make sure we handle "almost valid" debug > info gracefully... This last category is really interesting (and, unfortunately, given our current testing strategy, almost entirely untested). I think the proper thing here is that of having tooling that generates broken debug info, as yaml2obj can generate broken object files, and test with them. lldb does a great deal of work trying to "recover" with a lot of heuristics in case debug info are wrong but not that off. In order to have better control of this codepath, we need to have a better testing for this case, otherwise this will break (and we'll be forced to remove the codepath entirely). -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Testsuite in lldb & possible future directions
On Wed, Feb 7, 2018 at 9:32 AM, Pavel Labath wrote:
> On 6 February 2018 at 15:51, Davide Italiano wrote:
>>
>> FWIW, I strongly believe we should all agree on a configuration to run
>> tests and standardize on that.
>> It's unfortunate that we have two build systems, but there are plans
>> to move away from manually generating xcodebuild, as many agree it's a
>> terrible maintenance burden.
>> So, FWIW, I'll share my conf (I'm on high Sierra):
>>
>>
>> git clone https://github.com/monorepo
>> symlink clang -> tools
>> symlink lldb -> tools
>> symlink libcxx -> projects (this particular one has caused lots of
>> trouble for me in the past, and I realized it's undocumented :()
>>
>> cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm
>> ninja check-lldb
>>
> Right, so I tried following these instructions as precisely as I could.
>
> - The first thing that failed is the libc++ link step (missing
> -lcxxabi_shared).
>
> So, I added libcxxabi to the build, and tried again.
> Aaand, I have to say the situation is much better now: I got two
> unexpected successes and one timeout:
> UNEXPECTED SUCCESS: test_lldbmi_output_grammar
> (tools/lldb-mi/syntax/TestMiSyntax.py)
> UNEXPECTED SUCCESS: test_process_interrupt_dsym
> (functionalities/thread/state/TestThreadStates.py)
> TIMEOUT: test_breakpoint_doesnt_match_file_with_different_case_dwarf
> (functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py)
>
> On the second run I got these results:
> FAIL: test_launch_in_terminal (functionalities/tty/TestTerminal.py)
> UNEXPECTED SUCCESS: test_lldbmi_output_grammar
> (tools/lldb-mi/syntax/TestMiSyntax.py)
> UNEXPECTED SUCCESS: test_process_interrupt_dwarf
> (functionalities/thread/state/TestThreadStates.py)
>
>
> So, checking out libc++ certainly helped (this definitely needs to be
> documented somewhere) a lot. Of these, the MI test seems to be failing
> consistently. The rest appear to be flakes. I am attaching the logs
> from the second run, but there doesn't appear to be anything
> interesting there...
Terrific that we're making progress! I plan to take a look at the
`lldb-mi` failure soon, as I can reproduce it here fairly
consistently.
About the others, we've seen
functionalities/breakpoint/breakpoint_case_sensitivity/TestBreakpointCaseSensitivity.py
failing on the bots and I think might be due to a spotlight issue
Adrian found (and fixed).
You might still have `.dSYM` bundles from stale build directories, i.e.
To fix this, you need to wipe out all old build artifacts:
- Inside of the LLDB source tree:
$ git clean -f -d
- Globally:
$ find / -name a.out.dSYM -exec rm -rf \{} \;
This s a long shot, but might help you
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding D language demangling support
On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev wrote: > I made it work: > https://github.com/llvm-mirror/lldb/pull/3 > (note: also requires the D plugin on D side which I can submit to > another repo separately, and which is small) > > not sure if lldb accepts github PR's but that's the simplest I could do > > No, llvm/lldb is still on svn so we don't really accept pull requests yet. You can submit a new review on Phabricator though. That said, thank you for your contribution. For new languages, we want to have a high quality barrier for entry. I really appareciate the fact that you took the time to split in multiple patches. Every change that needs to be committed to lldb needs to have a test associated. You may consider taking a look at the tests in `lit/` or the ones in `test/` and add tests for your changes. Don't hesitate to ask if you get stuck/have other questions. Thank you, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
On Mon, Feb 26, 2018 at 9:01 PM, Timothee Cour via lldb-dev wrote: > https://github.com/llvm-mirror/lldb/pull/3 > > it would be *really* nice if llvm or lldb accepted industry standard > github PR's, at least as an option. Would make contributing so much > easier for outsiders See the other thread as well. https://llvm.org/docs/Phabricator.html Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] increase timeout for tests?
Hi, I've noticed some of the tests we have trigger timeouts when running in debug. TIMEOUT: test_NSError_p_dwarf (lang/objc/foundation/TestObjCMethods2.py) TIMEOUT: test_expression_lookups_objc_dwarf (lang/objc/foundation/TestObjCMethods.py) TIMEOUT: test_expressions_in_literals_dsym (lang/objc/objc-new-syntax/TestObjCNewSyntax.py) TIMEOUT: test_frame_var_after_stop_at_interface_gmodules (lang/objc/real-definition/TestRealDefinition.py) TIMEOUT: test_frame_variable_across_modules_gmodules (lang/objc/hidden-ivars/TestHiddenIvars.py) TIMEOUT: test_kvo_with_run_command_gmodules (functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py) TIMEOUT: test_long_long_type_gmodules (types/TestIntegerTypesExpr.py) TIMEOUT: test_long_type_gmodules (types/TestIntegerTypes.py) TIMEOUT: test_rdar11106605_with_run_command_gmodules (functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py) TIMEOUT: test_sb_api_listener_event_process_state (api/multithreaded/TestMultithreaded.py) TIMEOUT: test_scope_ambiguity_after_using_lookup_with_run_command_gmodules (lang/cpp/namespace/TestNamespaceLookup.py) TIMEOUT: test_set_auto_confirm_gmodules (settings/TestSettings.py) TIMEOUT: test_step_over_load_gmodules (functionalities/load_unload/TestLoadUnload.py) TIMEOUT: test_uint32_t_gmodules (lang/cpp/enum_types/TestCPP11EnumTypes.py) There's nothing fundamentally broken with these tests, it's just that they take forever. What do you think about increasing the timeout for single tests? Alternatively, we could start splitting these tests into smaller tests. Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote: > It would be great to look into these and see what is taking so long. Some > tests are doing way too much work and should be split up. But it would be > great to see if we have any tests that are not good tests and are just taking > too much time for no reason (like the watchpoint tests were that Pavel fixed). > I tend to agree with you. This is important. Pavel, is there a systematic way you use to profile test cases? Maybe we should consider having a testsuite mode where we warn for slow tests (or revamp the profiling mechanism, if there's one). Thanks! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev wrote: > I've registered to > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent > my patch via that email to lldb-comm...@lists.llvm.org but doesn't > appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long > does it take for > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to > subscribe? > Again, please sign-up for Phabricator as pointed out on the previous mail and submit the patch there https://llvm.org/docs/Phabricator.html > Still not sure why github PR's can't be accepted to remove all this > friction for outside developpers. > Because llvm main repo is still on svn. Once the migration to GitHub will happen, probably PR will be accepted at some point. Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
On Fri, Mar 9, 2018 at 3:45 AM, Pavel Labath wrote:
>
>
>
> On Thu, 8 Mar 2018 at 18:40, Davide Italiano wrote:
>>
>> On Thu, Mar 8, 2018 at 10:29 AM, Greg Clayton wrote:
>> > It would be great to look into these and see what is taking so long.
>> > Some tests are doing way too much work and should be split up. But it would
>> > be great to see if we have any tests that are not good tests and are just
>> > taking too much time for no reason (like the watchpoint tests were that
>> > Pavel fixed).
>> >
>>
>> I tend to agree with you. This is important. Pavel, is there a
>> systematic way you use to profile test cases?
>> Maybe we should consider having a testsuite mode where we warn for
>> slow tests (or revamp the profiling mechanism, if there's one).
>>
>> Thanks!
>
>
> I don't have any fancy mechanism for profiling this. I just hacked the
> process_file function in dosep.py to measure the time each test takes and
> report it if it exceeds a certain threshold. Then I just looked at the tests
> that seemed like they are taking more time than they ought to.
>
> This is the patch, in it's entirety:
> --- a/packages/Python/lldbsuite/test/dosep.py
> +++ b/packages/Python/lldbsuite/test/dosep.py
> @@ -489,8 +489,13 @@ def process_file(test_file, dotest_argv,
> inferior_pid_events):
> timeout = (os.getenv("LLDB_%s_TIMEOUT" % timeout_name) or
> getDefaultTimeout(dotest_options.lldb_platform_name))
>
> +import time
> +t = time.time()
> results.append(call_with_timeout(
> command, timeout, base_name, inferior_pid_events, test_file))
> +t = time.time() - t
> +if t > 20:
> +print("XX %s:
> %f"%(base_name, t))
>
> # result = (name, status, passes, failures, unexpected_successes)
> timed_out = [name for name, status, _, _, _ in results
>
> We could try to make this more fancy, but I'm not sure worth it. It just
> occurred to me you can achieve a similar effect by running the test suite
> with a reduced timeout threshold. Something like "LLDB_TEST_TIMEOUT=20s
> ninja check-lldb" should do the trick. At one point Todd also implemented a
> mechanism for recording what the test is doing before we time out and kill
> it. The idea was that this would help us determine what the test was doing
> when it was killed (and whether it was really stuck, or just slow). However,
> I've never used this, so I have no idea what's the state of it.
>
> I am not opposed to raising the timeout threshold, but before we do that, we
> should check whether it will actually help. I.e., whether the test is just
> slow, or it sometimes hangs (I think TestMultithreaded is a good candidate
> for the latter). Can you check what is the time those tests take to run
> individually? Current osx timeout (dosep.py:getDefaultTimeout) is set to 6
> minutes, so if the tests normally take much shorter than this (less than 2
> minutes?), I think there is something else going on, and increasing the
> timeout will not help.
>
> Another interesting thing may be to check the system load while running the
> test suite. Nowadays, lldb will sometimes spawn N (where N is the number of
> cpus) threads to do debug info parsing, so when we run N tests in parallel,
> we may end up with N^2 threads competing for N cpus. I've never seen this to
> be an issue as our tests generally don't have that much debug info to begin
> with, but I don't think we've ever investigated this either...
>
> BTW: This is my list of tests that take over 20 seconds (I ran it on linux
> so it does not include any osx-specific ones):
> 20.729438 TestWatchpointCommands.py
> 21.158373 TestMiData.py
> 22.018853 TestRecursiveInferior.py
> 22.692744 TestInferiorCrashing.py
> 22.986511 TestLinuxCore.py
> 23.073790 TestInferiorAssert.py
> 23.193351 TestAnonymous.py
> 24.539430 TestMiStack.py
> 25.232940 TestUnwindExpression.py
> 26.608233 TestSetWatchlocation.py
> 28.977390 TestWatchLocation.py
> 29.057234 TestMultithreaded.py
> 29.813142 TestCPP11EnumTypes.py
> 30.830618 TestWatchLocationWithWatchSet.py
> 32.979785 TestThreadStates.py
> 33.435421 TestTargetWatchAddress.py
> 36.902618 TestNamespaceLookup.py
> 37.705945 TestMiSymbol.py
> 38.735631 TestValueObjectRecursion.py
> 46.870848 TestLldbGdbServer.py
> 49.594663 TestLoadUnload.py
> 52.186429 TestIntegerTypes.py
> 55.340360 TestMiExec.py
> 56.148259 TestIntegerTypesExpr.py
> 110.121061 TestMiGdbSetShow.py
>
> The top one is an lldb-mi test, and this one takes long for a very silly
> reason: When a test is xfailed because lldb-mi does not produce the expected
> output, pexpect will keep waiting, hoping that it will eventually produce a
> line that matches it's regex. This times out after 30 seconds, so any
> xfailed lldb-mi test will take at least that long. I'm not sure how to fix
> this without revamping the way we do lldb-mi testing (which would probably
> be a good thing, but I don't see anyone queuing
Re: [lldb-dev] increase timeout for tests?
On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham wrote:
> The problem with having no timeouts is that you have to then be fairly
> careful how you write tests. You can't do:
>
> while (1) {
>print("Set a breakpoint here and hit it a few times then stop the test");
> }
>
> because if the breakpoint setting fails the test can run forever. And we
> wait forever to launch or attach to a process internally in lldb, so if you
> mess up attaching or launching in some situation, that again makes the test
> run forever. The timeouts are a backstop so you will get useful results from
> the testsuite in the case of this sort of error.
>
I see this. So, maybe we should set this to a ridiculously large value
(e.g. 30/60 minutes)? FWIW, I have at home that's slow enough that the
testsuite times out more often, and that's not great (the funny part
is that there's nothing inherently wrong with the tests :) Would you
be fine with such a middle ground, Jim?
Thanks,
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote: > I think we should get some data before pulling numbers out of our sleeves. > If we can get some numbers on the slowest machine that we have around, then > we should be able to specify the timeout as some multiple of the slowest > test. For example, for me the slowest test takes around 110 seconds. The > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long does > the slowest test take for you? If we set the timeout as 3x or 4x that > number, we should create a sufficiently large buffer and still avoid > half-hour waits. > The longest test takes over 300 seconds. This is a late 2013 Mac Pro, so, definitely not the newest machine out there (but also something fairly high spec). For the archives, my conf is something like; cmake -GNinja ../llvm && ninja check-lldb Thanks! -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
I'll re-run the test and send you a list. Thank you! -- Davide On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath wrote: > Aha, in that case, it definitely sounds like increasing the timeout is in > order. I would still go for something less than 30 minutes, but I don't care > about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if > tests taking long to time out start bugging me. > > BTW, do you know which test is that? Is it one of the tests I have listed in > one of the previous emails? > > On Tue, 13 Mar 2018 at 14:52, Davide Italiano wrote: >> >> On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote: >> > I think we should get some data before pulling numbers out of our >> > sleeves. >> > If we can get some numbers on the slowest machine that we have around, >> > then >> > we should be able to specify the timeout as some multiple of the slowest >> > test. For example, for me the slowest test takes around 110 seconds. The >> > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long >> > does >> > the slowest test take for you? If we set the timeout as 3x or 4x that >> > number, we should create a sufficiently large buffer and still avoid >> > half-hour waits. >> > >> >> The longest test takes over 300 seconds. This is a late 2013 Mac Pro, >> so, definitely not the newest machine out there (but also something >> fairly high spec). >> For the archives, my conf is something like; cmake -GNinja ../llvm && >> ninja check-lldb >> >> Thanks! >> >> -- >> Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
Few examples: 360 out of 617 test suites processed - TestObjCMethods.py XX TestObjCMethods.py: 363.726592 381 out of 617 test suites processed - TestHiddenIvars.py XX TestHiddenIvars.py: 363.887766 387 out of 617 test suites processed - TestObjCNewSyntax.py XX TestObjCNewSyntax.py: 363.842807 600 out of 617 test suites processed - TestDataFormatterObjC.py XX TestDataFormatterObjC.py: 388.414883 617 out of 617 test suites processed - TestLoadUnload.py XX TestLoadUnload.py: 363.372328 On Tue, Mar 13, 2018 at 9:49 AM, Davide Italiano wrote: > I'll re-run the test and send you a list. > > Thank you! > > -- > Davide > > On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath wrote: >> Aha, in that case, it definitely sounds like increasing the timeout is in >> order. I would still go for something less than 30 minutes, but I don't care >> about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if >> tests taking long to time out start bugging me. >> >> BTW, do you know which test is that? Is it one of the tests I have listed in >> one of the previous emails? >> >> On Tue, 13 Mar 2018 at 14:52, Davide Italiano wrote: >>> >>> On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath wrote: >>> > I think we should get some data before pulling numbers out of our >>> > sleeves. >>> > If we can get some numbers on the slowest machine that we have around, >>> > then >>> > we should be able to specify the timeout as some multiple of the slowest >>> > test. For example, for me the slowest test takes around 110 seconds. The >>> > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long >>> > does >>> > the slowest test take for you? If we set the timeout as 3x or 4x that >>> > number, we should create a sufficiently large buffer and still avoid >>> > half-hour waits. >>> > >>> >>> The longest test takes over 300 seconds. This is a late 2013 Mac Pro, >>> so, definitely not the newest machine out there (but also something >>> fairly high spec). >>> For the archives, my conf is something like; cmake -GNinja ../llvm && >>> ninja check-lldb >>> >>> Thanks! >>> >>> -- >>> Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] increase timeout for tests?
On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham wrote: > It sounds like we timing out based on the whole test class, not the > individual tests? If you're worried about test failures not hanging up the > test suite the you really want to do the latter. > > These are all tests that contain 5 or more independent tests. That's > probably why they are taking so long to run. > > I don't object to having fairly long backstop timeouts, though I agree with > Pavel that we should choose something reasonable based on the slowest running > tests just so some single error doesn't cause test runs to just never > complete, making analysis harder. > Vedant (cc:ed) is going to take a look at this as he's babysitting the bots for the week. I'll defer the call to him. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Displaying custom types in STL containers
On Mon, Mar 19, 2018 at 6:04 PM, Florin Trofin via lldb-dev wrote: > Ok,but how do you debug this? Debugging the debugger's formatter seems > non-trivial. Are there any guides/steps? > I generally recommend enabling logs (through `log enable lldb -f ~/somefile.txt`) and then work back from there. The logs tend to contain a lot of informations so I'd try with few channels. I'd start with `formatters`. To get a full list you can try: (lldb) log list (lldb) log help This helped me to solve a few issues I would've otherwise had no clue where to start (once I understand the context from the formatter, I generally grep in the source code & set breakpoints). Don't hesitate to ask if you have other questions. Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] cmake incremental OSX is red
I'm currently bisecting, but this is a FYI (in case it's obvious to anybody) https://ci.swift.org/job/oss-lldb-incremental-osx-cmake/169/ = Issue Details = FAIL: test_expr_symbols_dsym (expression_command/test/TestExprs2.py) FAIL: test_expr_symbols_dwarf (expression_command/test/TestExprs2.py) FAIL: test_expr_symbols_gmodules (expression_command/test/TestExprs2.py) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] cmake incremental OSX is red
Back to green http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/5871/console Thanks! -- Davide On Tue, Mar 20, 2018 at 10:32 AM, Pavel Labath wrote: > That check was separated out from a larger test so we could put skipIfLinux > around it (in r327977). I'm not sure why it's failing, but it's probably > some silly typo. Unfortunately I don't have time to look at it today. > > I am hoping that the fix is obvious. If it's not, you can revert that patch, > and I'll check it out tomorrow. > > pl > > > On Tue, 20 Mar 2018 at 17:22, Davide Italiano via lldb-dev > wrote: >> >> I'm currently bisecting, but this is a FYI (in case it's obvious to >> anybody) >> >> https://ci.swift.org/job/oss-lldb-incremental-osx-cmake/169/ >> >> >> = >> Issue Details >> = >> FAIL: test_expr_symbols_dsym (expression_command/test/TestExprs2.py) >> FAIL: test_expr_symbols_dwarf (expression_command/test/TestExprs2.py) >> FAIL: test_expr_symbols_gmodules (expression_command/test/TestExprs2.py) >> >> >> -- >> Davide >> ___ >> 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] Anybody using the GUI?
Good day. While trying to implement a command in lldb I noticed lldb has this awesome `gui` command that opens an ncurses GUI. I find it really useful and I wanted to play with it a bit, but I wasn't really able to get it working. In particular, I tried to press enter on `target create` or `attach` but nothing happens. Greg, as you wrote the original implementation, can you please explain how this is supposed to work? Are you actively interested in maintaining this mode? Thanks! -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FileSpec and normalization questions
IIRC We have path normalization functions in llvm, have you looked at them?
Thanks,
--
Davide
On Thu, Apr 19, 2018 at 11:14 AM, Greg Clayton via lldb-dev
wrote:
> We currently have DWARF that has a DW_AT_comp_dir that is set to "./"
> followed by any number of extra '/' characters. I would like to have this
> path normalized as we parse the DWARF so we don't end up with line tables
> with a variety of ".//+" prefixes on each source file.
>
> While looking to solve this issue, I took a look at the functionality that
> is in FileSpec right now. In:
>
> void FileSpec::SetFile(llvm::StringRef pathname, bool resolve, PathSyntax
> syntax);
>
>
> This function always calls a cheaper normalize function:
>
> namespace {
> void Normalize(llvm::SmallVectorImpl &path, FileSpec::PathSyntax
> syntax);
> }
>
> This function does nothing for posix paths, but switches backward slashes to
> forward slashes.
>
> We have a FileSpec function named FileSpec::GetNormalizedPath() which will
> do much more path normalization on a path by removing redundant "." and ".."
> and "//".
>
> I can fix my DWARF issue in a few ways:
> 1 - fix FileSpec::SetFile() to still call ::Normalize() but have it do more
> work and have it normalize out the and redundant or relative path info
> 2 - call FileSpec::GetNormalizedPath() on each comp dir before using it to
> actually normalize it
>
> The main question is: do we want paths floating around LLDB that aren't
> normalized? It seems like having a mixture of theses path will lead to
> issues in LLDB so I would vote for solution #1.
>
> Also, looking at the tests for normalizing paths I found the following pairs
> of pre-normalized and post-normalization paths for posix:
>
> {"//", "//"},
> {"//net", "//net"},
>
> Why wouldn't we reduce "//" to just "/" for posix? And why wouldn't we
> reduce "//net" to "/net"?
>
> Also I found:
>
> {"./foo", "foo"},
>
> Do we prefer to not have "./foo" to stay as "./foo"? Seems like if users
> know that their debug info has line table entries that are "./foo/foo.c"
> that they might type this in:
>
> (lldb) b ./foo/foo.c:12
>
> But this will fail since it might not match the "foo/foo.c:12" that might
> result from path normalization. We don't normalize right now so it doesn't
> matter and things would match, but part of my fix is normalizing a path in
> the DWARF that is currently ".foo/foo.c" down to either
> "./foo/foo.c" or "foo/foo.c" so it will matter depending on what we decide
> here.
>
> Any input would be appreciated.
>
> Greg Clayton
>
>
> ___
> 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] clang::VersionTuple
Fred is probably the person who can answer this question On Tue, May 8, 2018 at 11:06 AM, Zachary Turner wrote: > +davide, +aprantl for the Apple perspective. > > > On Tue, May 8, 2018 at 10:04 AM Greg Clayton wrote: >> >> >> On May 8, 2018, at 9:47 AM, Zachary Turner wrote: >> >> We don’t want the lowest levels of lldb to depend on clang. If this is >> useful we should move it from clang to llvm and use llvm::VersionTuple >> >> >> I agree, though this move will cause merging issues for many that have >> repositories that link against older llvm/clang. Doesn't affect me anymore, >> but Apple will be affected. >> >> Greg >> >> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >> wrote: >>> >>> No issues from me. >>> >>> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >>> > wrote: >>> > >>> > While moving Args around, I noticed that we have a bunch of >>> > functions/classes that pass/store version numbers as a triplet of >>> > integers >>> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper >>> > class >>> > for that when I noticed clang::VersionTuple, which is pretty much what >>> > I >>> > wanted out of the box. >>> > >>> > Now there are small differences between this class, and what we have >>> > now: >>> > it has an extra fourth "build" field, and it uses only 31 bits to >>> > represent >>> > the values. None of these seem to matter (particularly as we are >>> > converting our representation into this struct in some places) that >>> > much, >>> > but before I go through the trouble of pulling this class into llvm >>> > (although technically possible, it seems wrong to pull a clang >>> > dependency >>> > at such a low level), I wanted to make sure we are able to use it. >>> > >>> > Do you see any reason why we could not replace our version triplets >>> > with >>> > clang::VersionTuple ? >>> > >>> > cheers, >>> > pl >>> > ___ >>> > 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] LLDB Process Attach Failed When Waiting
On Thu, May 31, 2018 at 12:40 PM, Ryan Lovelett via lldb-dev wrote: > Well at least there is a little good news. I understood way more of those > logs than I thought I did. > > So two issues here: > 1 - we need a better error message when vAttachWait returns unsupported > 2 - fix lldb-server to support vAttachWait > > > A few questions. > > What is the protocol here? Can/should I report the issues at > https://bugs.llvm.org/ ? Or is that something that a project member needs to > do? Assuming that I can, would this be two seperate issues or one "large" > issue? > You can open a bug on bugzilla (you can ask an account via e-mail). > Barring that this is not something someone else might implement > better/faster than me. Considering I have zero LLDB development experience > is this something that I could tackle? > You can try and see how far you get (and ask questions, either here or on IRC oftc.net/#lldb) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] TestExprCompletion failing
Raphael, this test has been failing for a while. http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/9755/console Testing Time: 466.83s Failing Tests (1): lldb-Suite :: expression_command/completion/TestExprCompletion.py Can you please take a look? Thanks! -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] apples, pears etc: how to use __builtin_availability() elsewhere?
On Thu, Sep 13, 2018 at 2:56 AM René J.V. Bertin via lldb-dev wrote: > > Hi, > > clang has this nice runtime OS version checker but I cannot seem to find if > this is useable anywhere except on Apple OSes. > For ObjC (and thus @available()) one can still argue that the language isn't > of much use anywhere else, but that (lousy) argument doesn't fly > for__builtin_available() . > > Is there a list of known other platforms somewhere, or else is there at least > a token that makes the test return false when the current platform is not > listed? > > If not, how is that NOT a bug? > This is lldb-dev, the lldb debugger mailing list. You may consider directing your question to cfe-dev (the clang mailing list). -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [LLD] How to get rid of debug info of sections deleted by garbage collector
On Wed, Sep 19, 2018 at 8:35 PM Venkata Ramanaiah Nalamothu via lldb-dev wrote: > > Hi, > > After compiling an example.cpp file with "-c -ffunction-sections" and linking > with "--gc-sections" (used ld.lld), I am still seeing debug info for the > sections deleted by garbage collector in the generated executable. > > Are there any compiler/linker options and/or other tools in LLVM to get rid > of the above mentioned unneeded debug info? > > If such options does not exist, what needs to be changed in the linker (lld)? > It's not easy. It's also format dependent. I assume you're talking about ELF here. In first approximation, the linker does not GC section marked without SHF_ALLOC. At some point we did an analysis and in practice it turns out most of them are debug info. I seem to recall that Cary Coutant had a proposal for ld.gold on how to reclaim them without breaking, but I can't find it easily (cc:ing him directly). Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb
On Tue, Oct 9, 2018 at 3:56 AM Chirag Patel via lldb-dev wrote: > > Hello all, > > > > I am looking into adding the new typesystem support for languages like > PLI/COBOL. > > Is anybody actively working/looking on this? > > > > Regards, > > Not I'm aware of. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] DW_OP_deref handling
Hi Greg,
I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
I wasn’t able to craft an easy C++ testcase, so I’ll start from my
motivating (swift) example.
Given the following code:
func use(_ t : T) {}
func single(_ t : T) {
let x = t
use(x)
}
let s = "hello"
single(s)
The IR emitted for the local binding `x` in `single` is an alloca
containing the address of `x`. Hence, the DWARF, correctly contains a
DW_OP_deref expression, i.e.:
0x00da: TAG_variable [9]
AT_location( fbreg -16, deref )
AT_name( "x" )
AT_decl_file(
"/Users/dcci/work/swift/build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-x86_64/bin/pat.swift"
)
AT_decl_line( 4 )
AT_type( {0x0204} ( $sxD ) )
When I debug this with lldb, I expect lldb to print the value that’s
pointed by %rbp - 16,
i.e.
(lldb) register read $rbp
rbp = 0x7ffeefbff860
(lldb) mem read 0x7ffeefbff850
0x7ffeefbff850: 10 f8 bf ef fe 7f 00 00 b8 32 4d 00 01 00 00 00
....?2M.
0x7ffeefbff860: c0 f8 bf ef fe 7f 00 00 64 09 00 00 01 00 00 00
?...d...
So, the value that I expected to be printed is 0x7ffeefbff810.
What I instead see in the debugger is:
(T) x =
The value `0xe500` happens to be the value that’s pointed
by the address 0x7ffeefbff810, that is:
(lldb) mem read 0x7ffeefbff810
0x7ffeefbff810: 00 00 00 00 00 00 00 e5 68 65 6c 6c 6f 00 00 00
...?hello...
0x7ffeefbff820: 05 00 00 00 00 00 00 00 40 32 4d 00 01 00 00 00
@2M.
Is this an expected behavior? I did expect DW_OP_deref to just do a
single dereference and not two. It looks like when we call
`UpdateValue()` in lldb we do have the correct value in `m_value`, but
GetPointerValue() ends up printing the value that’s *pointed by*
what’s in `m_value`, i.e.
m_integer = {
U = {
VAL = 0x7ffeefbff810
pVal = 0x7ffeefbff810
}
as this is a LoadAddress. Greg, as you wrote this code (and touched it
last), what do you expect to be the correct semantic here?
Removing a dereference from DW_OP_deref in the DWARFASTParser works
around the issue, but I’m fairly sure it’s the incorrect fix. Are we
maybe setting the value type incorrectly?
Best,
—
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
On Thu, Oct 11, 2018 at 11:16 AM Greg Clayton wrote:
>
> The issue is DW_OP_deref dereferences a pointer and pushes it onto the stack.
> The code currently, for a load address that is on top of the stack does:
>
> Value::ValueType value_type = stack.back().GetValueType();
> switch (value_type) {
> case Value::eValueTypeLoadAddress:
> if (exe_ctx) {
> if (process) {
> lldb::addr_t pointer_addr =
> stack.back().GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
> Status error;
> lldb::addr_t pointer_value =
> process->ReadPointerFromMemory(pointer_addr, error);
> if (pointer_value != LLDB_INVALID_ADDRESS) {
> stack.back().GetScalar() = pointer_value;
> stack.back().ClearContext();
> } else {
> return false;
> }
>
> Here we just use "stack.back()" to access the item at the top of the
> expression value stack. The top value has a Value::ValueType of
> Value::eValueTypeLoadAddress. We don't reset this value to be
> Value::eValueTypeScalar, but we probably should and that will probably fix
> this issue.
>
> DWARF5 finally added the ability to track what each value means on the
> expression stack. Prior to DWARF 5, we had no idea what each entry on the
> expression value stack was (file address, load address
> (Value::eValueTypeLoadAddress), plain value (Value::eValueTypeScalar). We
> have tracked this info for a while now, but the DWARF5 spec is much more
> specific on how things should be treated. From the spec:
>
> DW_OP_deref
>
> The DW_OP_deref operation pops the top stack entry and treats it as an
> address. The popped value must have an integral type. The value retrieved
> from that address is pushed, and has the generic type. The size of the data
> retrieved from the dereferenced address is the size of an address on the
> target machine.
>
> No the "The value retrieved from that address is pushed, and has the generic
> type." statement. In LLDB this means the value's ValueType should be set to
> Value::eValueTypeScalar.
>
> So try modifying the code with
> stack.back().SetValueType(Value::eValueTypeScalar) after the
> stack.back().ClearContext():
>
> if (pointer_value != LLDB_INVALID_ADDRESS) {
> stack.back().GetScalar() = pointer_value;
> stack.back().ClearContext();
> stack.back().SetValueType(Value::eValueTypeScalar);
> } else {
> return false;
> }
>
> That might fix things.
>
> The way the expression ends up right now we end up with an expression stack
> saying that the value is a load address which means we must read the value
> from memory in order to find it. This would be the right thing to do if your
> location expression was:
>
> 0x00da: TAG_variable [9]
> AT_location( fbreg -16 )
> AT_name( "x" )
> AT_decl_file(...)
> AT_decl_line( 4 )
> AT_type( {0x0204} ( $sxD ) )
>
> Note I removed the "deref" from the location expression. In this case the
> variable would need to be read from memory. If the value was to be in a
> register, then the location would be:
>
> 0x00da: TAG_variable [9]
> AT_location( reg16 )
> AT_name( "x" )
> AT_decl_file(...)
> AT_decl_line( 4 )
> AT_type( {0x0204} ( $sxD ) )
>
> Then the value would be in register 16 itself (not dereferenced).
>
> Hope this all makes sense. If you have any questions let me know.
>
Thanks. I tend to agree this is the right thing to do, but it happens
to break many tests in the debugger.
Failing Tests (26):
lldb-Suite :: functionalities/unwind/sigtramp/TestSigtrampUnwind.py
lldb-Suite :: lang/c/blocks/TestBlocks.py
lldb-Suite :: lang/swift/address_of/TestSwiftAddressOf.py
lldb-Suite ::
lang/swift/expression/class_constrained_protocol/TestClassConstrainedProtocol.py
lldb-Suite ::
lang/swift/expression/exclusivity_suppression/TestExclusivitySuppression.py
lldb-Suite ::
lang/swift/expression/optional_amibiguity/TestOptionalAmbiguity.py
lldb-Suite :: lang/swift/expression/scopes/TestExpressionScopes.py
lldb-Suite :: lang/swift/expression/weak_self/TestWeakSelf.py
lldb-Suite ::
lang/swift/foundation_value_types/data/TestSwiftFoundationTypeData.py
lldb-Suite ::
lang/swift/foundation_value_types/date/TestSwiftFoundationTypeDate.py
lldb-Suite ::
lang/swift/foundation_value_types/indexpath/TestSwiftFoundationTypeIndexPath.py
lldb-Suite ::
lang/swift/foundation_value_types/measurement/TestSwiftFoundationTypeMeasurement.py
lldb-Suite ::
lang/swift/foundation_value_types/notification/TestSwiftFoundationTypeNotification.py
lldb-Suite ::
lang/swift/foundation_value_types/url/TestSwiftFoundationTypeURL.py
lldb-Suite ::
lang/swift/foundation_value_types/uuid/TestSwiftFoundationTypeUUID.py
lldb-Suite :: lang/swift/generic_tuple/TestSwiftGenericTuple.py
lldb-Suite :: lang/swift/po/sys_types/TestSwiftPOSysTypes.py
Re: [lldb-dev] DW_OP_deref handling
On Thu, Oct 11, 2018 at 1:38 PM Greg Clayton wrote: > > I am happy to look at any DWARF expressions you have and help figure out > where the change needs to go or how the expression need to be fixed. > Thank you for your help, it's greatly appreciated. hopefully we'll have a more precise debugger after this effort :) -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
Follow up. This turned out to be a bug in the swift specific support,
so I don't think the DWARF parser code is wrong here.
Thanks!
--
Davide
On Thu, Oct 11, 2018 at 10:52 AM Davide Italiano wrote:
>
> Hi Greg,
> I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
> I wasn’t able to craft an easy C++ testcase, so I’ll start from my
> motivating (swift) example.
>
> Given the following code:
>
> func use(_ t : T) {}
> func single(_ t : T) {
> let x = t
> use(x)
> }
> let s = "hello"
> single(s)
>
> The IR emitted for the local binding `x` in `single` is an alloca
> containing the address of `x`. Hence, the DWARF, correctly contains a
> DW_OP_deref expression, i.e.:
>
> 0x00da: TAG_variable [9]
> AT_location( fbreg -16, deref )
> AT_name( "x" )
> AT_decl_file(
> "/Users/dcci/work/swift/build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-x86_64/bin/pat.swift"
> )
> AT_decl_line( 4 )
> AT_type( {0x0204} ( $sxD ) )
>
> When I debug this with lldb, I expect lldb to print the value that’s
> pointed by %rbp - 16,
> i.e.
> (lldb) register read $rbp
> rbp = 0x7ffeefbff860
>
> (lldb) mem read 0x7ffeefbff850
> 0x7ffeefbff850: 10 f8 bf ef fe 7f 00 00 b8 32 4d 00 01 00 00 00
> ....?2M.
> 0x7ffeefbff860: c0 f8 bf ef fe 7f 00 00 64 09 00 00 01 00 00 00
> ?...d...
>
> So, the value that I expected to be printed is 0x7ffeefbff810.
>
> What I instead see in the debugger is:
> (T) x =
>
> The value `0xe500` happens to be the value that’s pointed
> by the address 0x7ffeefbff810, that is:
>
> (lldb) mem read 0x7ffeefbff810
> 0x7ffeefbff810: 00 00 00 00 00 00 00 e5 68 65 6c 6c 6f 00 00 00
> ...?hello...
> 0x7ffeefbff820: 05 00 00 00 00 00 00 00 40 32 4d 00 01 00 00 00
> @2M.
>
> Is this an expected behavior? I did expect DW_OP_deref to just do a
> single dereference and not two. It looks like when we call
> `UpdateValue()` in lldb we do have the correct value in `m_value`, but
> GetPointerValue() ends up printing the value that’s *pointed by*
> what’s in `m_value`, i.e.
>
> m_integer = {
> U = {
> VAL = 0x7ffeefbff810
> pVal = 0x7ffeefbff810
> }
>
> as this is a LoadAddress. Greg, as you wrote this code (and touched it
> last), what do you expect to be the correct semantic here?
>
> Removing a dereference from DW_OP_deref in the DWARFASTParser works
> around the issue, but I’m fairly sure it’s the incorrect fix. Are we
> maybe setting the value type incorrectly?
>
>
> Best,
>
>
> —
>
> Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] ASTImporter patches and improvements, please help
On Thu, Dec 6, 2018 at 6:39 AM Gábor Márton wrote:
>
> Hi Davide,
>
> Thank you for your email.
>
> > In particular, what's the error you get when lldb fails immediately running
> > the tests?
> > Also, have you checked libcxx and libcxx-abi in your build? We might
> > consider making that a mandatory dependency for the Cmake build.
>
> Finally I could run the test suite ("ninja check-lldb) on our macOS without
> errors. Here are my findings:
> 1) "sudo /usr/sbin/DevToolsSecurity --enable" is a must.
> 2) I indeed did not checked out libcxx. (libcxx-abi was not needed to have a
> successful run). Would be great to make that a mandatory dependency.
> 3) Besides that I recognized that "ninja check-lldb" target does not build
> all it's dependencies. E.g. lldb-server tests failed until I executed "ninja
> debugserver" before "ninja check-lldb". I am not sure, but I think "ninja
> obj2yaml" and "ninja llvm-pdbutil" are also prerequisites (and these targets
> seem not to be built by a simple "ninja" command).
>
Any chance you can submit fixes for this? Or, if you can't just open a
PR and I'll take a look.
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] When should ArchSpecs match?
On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev
wrote:
>
> I was puzzled by the behavior of ArchSpec::IsExactMatch() and
> IsCompatibleMatch() yesterday, so I created a couple of unit tests to
> document the current behavior. Most of the tests make perfect sense, but a
> few edge cases really don't behave like I would have expected them to.
>
> > {
> > ArchSpec A("arm64-*-*");
> > ArchSpec B("arm64-apple-ios");
> > ASSERT_FALSE(A.IsExactMatch(B));
> > // FIXME: This looks unintuitive and we should investigate whether
> > // this is the desired behavior.
> > ASSERT_FALSE(A.IsCompatibleMatch(B));
> > }
> > {
> > ArchSpec A("x86_64-*-*");
> > ArchSpec B("x86_64-apple-ios-simulator");
> > ASSERT_FALSE(A.IsExactMatch(B));
> > // FIXME: See above, though the extra environment complicates things.
> > ASSERT_FALSE(A.IsCompatibleMatch(B));
> > }
> > {
> > ArchSpec A("x86_64");
> > ArchSpec B("x86_64-apple-macosx10.14");
> > // FIXME: The exact match also looks unintuitive.
> > ASSERT_TRUE(A.IsExactMatch(B));
> > ASSERT_TRUE(A.IsCompatibleMatch(B));
> > }
> >
>
> Particularly, I believe that:
> - ArchSpec("x86_64-*-*") and ArchSpec("x86_64") should behave the same.
Yes.
> - ArchSpec("x86_64").IsExactMatch("x86_64-apple-macosx10.14") should be false.
I'm at a loss trying to understand how this could not be false.
It would mean that when we instantiate a Triple and we don't have an
arch we believe it's a Mach-O binary.
This sounds really wrong, and if there's code in lldb living under the
assumption this is true, we might consider getting rid of it (or
fixing it).
> - ArchSpec("x86_64-*-*").IsCompatibleMath("x86_64-apple-macosx") should be
> true.
>
Yes.
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] beginner bugs
[cross-posting this to llvm-dev for better visibility] I got a private mail from a student (prospective GSoC) who asked me what was the best way to start contributing to lldb. So, I decided to take some bugs and mark them as beginner, as there were none for the specific component). https://bugs.llvm.org/buglist.cgi?component=All%20Bugs&f1=keywords&list_id=151389&o1=equals&product=lldb&query_format=advanced&resolution=---&v1=beginner I'm willing to help if somebody is interested. Probably lldb-dev or #lldb on irc.oftc.net are also good places to ask questions as a bunch of us hang there. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] beginner bugs
On Sun, Dec 16, 2018 at 5:50 PM Davide Italiano wrote: > > [cross-posting this to llvm-dev for better visibility] > > I got a private mail from a student (prospective GSoC) who asked me > what was the best way to start contributing to lldb. So, I decided to > take some bugs and mark them as beginner, as there were none for the > specific component). > > https://bugs.llvm.org/buglist.cgi?component=All%20Bugs&f1=keywords&list_id=151389&o1=equals&product=lldb&query_format=advanced&resolution=---&v1=beginner > > I'm willing to help if somebody is interested. Probably lldb-dev or > #lldb on irc.oftc.net are also good places to ask questions as a bunch > of us hang there. > s/willing to/happy to/. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Signedness of scalars built from APInt(s)
While adding support for 512-bit integers in `Scalar`, I figured I
could add some coverage.
TEST(ScalarTest, Signedness) {
auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
auto s2 = Scalar(APInt(32, 12, true /* isSigned */ ));
ASSERT_EQ(s1.GetType(), Scalar::e_uint); // fails
ASSERT_EQ(s2.GetType(), Scalar::e_sint); // pass
}
The result of `s1.GetType()` is Scalar::e_sint.
This is because an APInt can't distinguish between "int patatino = 12"
and "uint patatino = 12".
The correct class in `llvm` to do that is `APSInt`.
I think there are at least a couple of possibilities to fix this:
1) Change the constructor in Scalar to always get an APSInt. This
would be fairly invasive but we could always query isSigned() to make
sure we instantiate the correct scalar type.
2) Change the implementation of Scalar(APInt v) to look at the sign
bit, and if that's set, treat the value as signed (and unsigned
otherwise). This will be definitely more correct than the current
implementation which always construct signed types from APInt(s), but
I'm not entirely sure of all the implications.
What do you think?
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Signedness of scalars built from APInt(s)
On Fri, Jan 4, 2019 at 1:57 PM Davide Italiano wrote:
>
> While adding support for 512-bit integers in `Scalar`, I figured I
> could add some coverage.
>
> TEST(ScalarTest, Signedness) {
> auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
> auto s2 = Scalar(APInt(32, 12, true /* isSigned */ ));
> ASSERT_EQ(s1.GetType(), Scalar::e_uint); // fails
> ASSERT_EQ(s2.GetType(), Scalar::e_sint); // pass
> }
>
> The result of `s1.GetType()` is Scalar::e_sint.
> This is because an APInt can't distinguish between "int patatino = 12"
> and "uint patatino = 12".
> The correct class in `llvm` to do that is `APSInt`.
>
Please note that this is also broken in the case where you have
APInt(32 /* bitWidth */, -323);
because of the way the constructor is implemented.
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Signedness of scalars built from APInt(s)
On Fri, Jan 4, 2019 at 3:54 PM Zachary Turner wrote: > > It seems like we have 3 uses of this constructor in LLDB. > > IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant. > IRForTarget.cpp: Constructs a Scalar for an llvm::Constant. > ClangASTContext.cpp: bitcasts an APFloat to an APInt. > > The first two we should just treat constants in LLVM IR as signed, so we > could construct an APSInt at the call-sites with signed=true. > OK, I think there might be subtleties we're missing right now but the best way is just try and see what happens. I'll send patches early next week. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [lit] check-all hanging
On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev wrote: > > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss wrote: >> >> >> >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny wrote: >> > >> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss wrote: >> > -llvm-dev + lldb-dev for the lldv test failures. >> > >> >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny wrote: >> >> >> >> All, >> >> >> >> Thanks for the replies. Kuba: For LLDB, when were things expected to >> >> have improved? It's possible things improved for me at some point, but >> >> this isn't something I've found time to track carefully, and I still see >> >> problems. >> >> >> >> I ran check-all a couple of times last night at r350238, which I pulled >> >> yesterday. Here are the results: >> >> >> >> ``` >> >> >> >> Testing Time: 5043.24s >> >> >> >> Unexpected Passing Tests (2): >> >> lldb-Suite :: functionalities/asan/TestMemoryHistory.py >> >> lldb-Suite :: functionalities/asan/TestReportData.py >> >> >> >> >> >> Failing Tests (54): >> >> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp >> >> Clang :: Modules/ExtDebugInfo.cpp >> >> Clang :: Modules/using-directive-redecl.cpp >> >> Clang :: Modules/using-directive.cpp >> >> Clang :: PCH/chain-late-anonymous-namespace.cpp >> >> Clang :: PCH/cxx-namespaces.cpp >> >> Clang :: PCH/namespaces.cpp >> >> LLDB :: ExecControl/StopHook/stop-hook-threads.test >> >> LeakSanitizer-AddressSanitizer-x86_64 :: >> >> TestCases/Linux/use_tls_dynamic.cc >> >> LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc >> >> MemorySanitizer-X86_64 :: dtls_test.c >> >> MemorySanitizer-lld-X86_64 :: dtls_test.c >> >> lldb-Suite :: >> >> functionalities/register/register_command/TestRegisters.py >> >> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py >> > >> > It’s hard to diagnose dotest failures without the log. >> > >> > (My last reply to this was rejected by the list because I wasn't >> > subscribed. Trying again.) >> > >> > I have no experience debugging lldb. Here's the lit output for the last >> > fail (now at r350377), but let me know if you want something more: >> > >> > ``` >> > FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py (59083 >> > of 59736) >> > TEST 'lldb-Suite :: >> > tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED >> > >> > lldb version 8.0.0 >> > LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin >> > LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin >> > Libc++ tests will not be run because: Unable to find libc++ installation >> > Skipping following debug info categories: ['dsym', 'gmodules'] >> > >> > Session logs for test failures/errors/unexpected successes will go into >> > directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces' >> > Command invoked: /home/jdenny/ornl/llvm-mono-git/lldb/test/dotest.py -q >> > --arch=x86_64 -s /home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces >> > --build-dir /home/jdenny/ornl/llvm-mono-git-build/lldb-test-build.noindex >> > -S nm -u CXXFLAGS -u CFLAGS --executable >> > /home/jdenny/ornl/llvm-mono-git-build/./bin/lldb --dsymutil >> > /home/jdenny/ornl/llvm-mono-git-build/./bin/dsymutil --filecheck >> > /home/jdenny/ornl/llvm-mono-git-build/./bin/FileCheck -C >> > /home/jdenny/ornl/llvm-mono-git-build/./bin/clang --env >> > ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy >> > /home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server >> > -p TestGdbRemoteRegisterState.py >> > UNSUPPORTED: LLDB >> > (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >> > test_grp_register_save_restore_works_no_suffix_debugserver >> > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) >> > FAIL: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >> > test_grp_register_save_restore_works_no_suffix_llgs >> > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >> > lldb-server exiting... >> > UNSUPPORTED: LLDB >> > (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >> > test_grp_register_save_restore_works_with_suffix_debugserver >> > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) >> > FAIL: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >> > test_grp_register_save_restore_works_with_suffix_llgs >> > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >> > lldb-server exiting... >> > == >> > FAIL: test_grp_register_save_restore_works_no_suffix_llgs >> > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >> > -- >> > Traceback (most recent call last): >> > File >> > "/home/jdenny/ornl/llvm-mon
Re: [lldb-dev] RFC: Simplifying SymbolFile interface
On Thu, Jan 10, 2019 at 12:43 AM Pavel Labath via lldb-dev wrote: > > On 09/01/2019 20:59, Zachary Turner via lldb-dev wrote: > > The Native PDB symbol file plugin I think is mostly complete. It's at > > least almost as good as the old Windows-only PDB plugin in 90% of ways, > > while actually being significantly better in other ways (for example, > > there was a test that took over 2 minutes to run with the Windows-only > > PDB plugin, which now takes about 2 seconds to run with the native PDB > > plugin. > > > > While implementing this, I ran into several things that made my life > > quite difficult, and only later found out that I could have saved myself > > a lot of headache and time if the SymbolFile interface had been a little > > simpler and easier to understand. > > > > Specifically, I'd like to remove the heavy use of SymbolContext in the > > SymbolFile / SymbolVendor interface and replace it with more narrow and > > targeted parameter lists. > > > > Consider the case of someone calling FindTypes. In theory, today they > > can fill out any combination of Target, Module, Function, Block, > > CompileUnit, LineEntry, and Symbol. That's 2^7 different possible ways > > the function can be called. While obviously not all of these > > combinations make sense, the fact is that it greatly increases the API > > surface, which is bad for test coverage, bad for ease of understanding, > > bad for usability, and leads to a lot of dead code. > > > > For a person implementing this function for the first time, and who may > > not know all the details about how the rest of LLDB works, this is quite > > daunting because there's an inherent desire to implement the function > > faithfully "just in case", since they don't know all of the different > > ways the function might be called. > > > > This results in wasted time on the developer's part, because they end up > > implementing a bunch of functionality that is essentially dead code. > > > > We can certainly document for every single function "The implementor > > should be prepared to handle the case of fields X, Y, and Z being set, > > and handle it in such and such way", but I think it's easier to just > > change the interface to be more clear in the first place. > > > > > > Here are the cases I identified, and a proposal for how I could change > > the interface. > > > > 1) SymbolFile::ParseTypes(SymbolContext&) > >* In the entire codebase, this is only called with a CompileUnit > > set. We should change this to be ParseTypesForCompileUnit(CompileUnit&) > > so that the interface is self-documenting. A patch with this change is > > here [https://reviews.llvm.org/D56462] > > > > 2) SymbolFile::ParseDeclsForContext(CompilerDeclContext) > >* This is intended to only be used for parsing variables in a block. > > But should it be recursive? It's impossible to tell from the function > > name, so callers can't use it correctly and implementors can't implement > > it correctly. I spent 4 days trying to implement a generic version of > > this function for the NativePDB plugin only to find out that I only > > actually cared about block variables. I would propose changing this to > > ParseVariableDeclsForBlock(Block&). > > > > 3) These functions: > > * ParseCompileUnitLanguage(SymbolContext&) > > * ParseCompileUnitFunctions(SymbolContext&) > > * ParseCompileUnitLineTable(SymbolContext&) > > * ParseCompileUnitDebugMacros(SymbolContext&) > > * ParseCompileUnitSupportFiles(SymbolContext&) > > > > are only for CompileUnits (as the name implies. I propose changing the > > parameter from a SymbolContext& to a CompileUnit&. > > > > 4) SymbolFile::ParseFunctionBlocks(SymbolContext&) > > * This is intended to be used when the SymbolContexts m_function > > member is set. I propose changing this to > > SymbolFile::ParseFunctionBlocks(Function&). > > > > 5) SymbolFile::ParseVariablesForContext(CompilerDeclContext) > > * This function is only called with the the Context being a CompileUnit, > > Function, and Block. But does it need to be recursive? For a Function > > and Block it seems to be assumed to be recursive, and for a CompileUnit > > it seems to be assumed to not be recursive. For the former case, it's > > not actually clear how this function differs from ParseGlobalVariables, > > and for the latter case I would propose changing this to > > ParseImmedateVariablesForBlock(Block&). > > > > 6) SymbolFile::FindTypes(SymbolContext&). > > * This function is only called with the m_module field set, and since a > > SymbolFile is already tied to a module anyway, the parameter appears > > unnecessary. I propose changing this to SymbolFile::FindAllTypes() > > > > 7) SymbolFile::FindNamespace(SymbolContext&, ConstString, DeclContext*) > > is only called with default-constructed (i.e. null) SymbolContexts, > > making the first parameter unnecessary. I propose changing this to > > FindNamespace(ConstString, DeclContext*) > > > > > > 8) Module::FindTypes(Sy
Re: [lldb-dev] LLDB bot health
On Fri, Jan 11, 2019 at 9:20 AM via lldb-dev wrote: > > Inspired by people recently asking about or filing bugs for test fails > that happen in their own environments, I thought I might do the same. > "But wait," I thought, "maybe some bots are already finding these." > > Which led me to discover: > > lldb-amd64-ninja-netbsd8 green > lldb-windows7-androidtest failures > lldb-x64-windows-ninja test failures > lldb-x86-windows-msvc2015out of disk space > lldb-x86_64-darwin-13.4 cmake errors > lldb-x86_64-ubuntu-14.04-android cmake errors > lldb-x86_64-ubuntu-14.04-buildserver green > lldb-x86_64-ubuntu-14.04-cmake test failures > Thanks for your feedback. As one of the people who encouraged users to report failures they see locally, I would like to point out I wasn't really aware of the existence of many of these bots. I'm aware there's a subset of people watching the MacOS bots, which are now in a decent state (as part of their day job). (I personally never heard of the darwin-13.4 bot but if overlaps with what the lldb greendragon bots are testing, it could be as well dismissed, i.e. http://lab.llvm.org:8080/green/view/LLDB/) I will personally watch these bots more closely, I cc:ed some of the people involved to see if we can make the situation better. Have you considered debugging some of the issues you're seeing locally? I'm pretty sure some help would be appreciated. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB bot health
On Fri, Jan 11, 2019 at 3:07 PM Stella Stamenova wrote: > > Thanks Davide, > > I think several of these bots have not been maintained for a while. One thing > we could do is try to ping the owners and see if it's possible to update the > bots or if they're no longer useful, then remove them. > I agree. I don't know who owns these bots, is there an easy way to find? (or just cc: them to these e-mail). We can then ask Galina to just remove the bots if nobody maintains them. Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [RFC]The future of pexpect
As you probably know (I didn’t), lldb embeds its own version of `pexpect-2.4`, which doesn’t support python3. This is the (relatively short) list of tests relying on pyexpect: testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect # 7 (EOF) testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect testcases/lldbtest.py:import pexpect testcases/driver/batch_mode/TestBatchMode.py:import pexpect testcases/driver/batch_mode/TestBatchMode.py:import pexpect testcases/driver/batch_mode/TestBatchMode.py:import pexpect testcases/driver/batch_mode/TestBatchMode.py:import pexpect testcases/lldbpexpect.py:import pexpect testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect testcases/darwin_log.py:import pexpect testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect testcases/benchmarks/frame_variable/TestFrameVariableResponse.py: import pexpect testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py: import pexpect testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py: import pexpect testcases/benchmarks/expression/TestExpressionCmd.py:import pexpect testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect testcases/benchmarks/startup/TestStartupDelays.py:import pexpect testcases/functionalities/command_regex/TestCommandRegex.py: import pexpect testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py: import pexpect testcases/functionalities/format/TestFormats.py:import pexpect (I count 14, but there might be something else). I audited all of them and from what I see they’re almost all testing the driver. I had a chat with my coworkers and we agreed it's reasonable to replace them with lit tests (as they're just running commands). This would allow us to get rid of an external dependency, which happened to be cause of trouble in the past. Are there any objections? Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
On Thu, Jan 31, 2019 at 10:09 AM Pavel Labath wrote: > > On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote: > > As you probably know (I didn’t), lldb embeds its own version of > > `pexpect-2.4`, which doesn’t support python3. > > This is the (relatively short) list of tests relying on pyexpect: > > > > testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect > > # 7 (EOF) > > testcases/tools/lldb-mi/lldbmi_testcase.py:import pexpect > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect > > testcases/tools/lldb-mi/signal/TestMiSignal.py:import pexpect > > testcases/lldbtest.py:import pexpect > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect > > testcases/driver/batch_mode/TestBatchMode.py:import pexpect > > testcases/lldbpexpect.py:import pexpect > > testcases/terminal/TestSTTYBeforeAndAfter.py:import pexpect > > testcases/darwin_log.py:import pexpect > > testcases/macosx/nslog/TestDarwinNSLogOutput.py:import pexpect > > testcases/benchmarks/stepping/TestSteppingSpeed.py:import pexpect > > testcases/benchmarks/frame_variable/TestFrameVariableResponse.py: > >import pexpect > > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py: > > import pexpect > > testcases/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py: > > import pexpect > > testcases/benchmarks/expression/TestExpressionCmd.py:import pexpect > > testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect > > testcases/benchmarks/expression/TestRepeatedExprs.py:import pexpect > > testcases/benchmarks/startup/TestStartupDelays.py:import pexpect > > testcases/functionalities/command_regex/TestCommandRegex.py: > > import pexpect > > testcases/functionalities/single-quote-in-filename-to-lldb/TestSingleQuoteInFilename.py: > > import pexpect > > testcases/functionalities/format/TestFormats.py:import pexpect > > > > (I count 14, but there might be something else). > > > > I audited all of them and from what I see they’re almost all testing the > > driver. > > I had a chat with my coworkers and we agreed it's reasonable to > > replace them with lit tests (as they're just running commands). > > This would allow us to get rid of an external dependency, which > > happened to be cause of trouble in the past. > > > > Are there any objections? > > > > Thanks, > > > > I'm not a fan of pexpect, and if these tests can be converted to lit, > then I'm all for it. But I do have a question. > > There is a class of tests that cannot be written in the current lit > framework, but they can with pexpect. A couple of weeks ago we had a > patch fixing a bug where pressing up arrow while searching through the > command history caused a crash. In the end a test for this was not > included because it was hard for a reason unrelated to pexpect, but > without pexpect (or something equivalent) writing a test for this would > be impossible. > I don't know about this, to be honest. Maybe lit should grow an interactive mode somehow to accomodate for this functionality? I'm not an expert in how it's implemented so that could be hard to achieve. FWIW, I haven't seen anything that really requires interactivity, but I have to admit I haven't looked really deeply. > What's our story for testing interactive command-line functionalities? > The way I see it, if we don't use pexpect, we'll either have to use some > other tool which simulates a realistic terminal, or write our own. (We > already have one attempt for this in > unittests/Editline/EditlineTest.cpp, but this would need more work to be > fully functional.) > > pl > > > PS: Does anyone actually use the benchmark tests? Can we just delete them? I don't know. Maybe Jim knows. I personally don't use them. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath wrote:
>
> On 31/01/2019 19:51, Zachary Turner wrote:
> > FileCheck the ansi escape codes seems like one possibility.
> >
> > In general I think you don't actually need to test true interactivity,
> > because the odds of there being a problem in the 2-3 lines of code that
> > convert the keyboard press to something else in LLDB are very unlikely
> > to be problematic, and the rest can be mocked.
>
>
> On 31/01/2019 20:02, Jim Ingham wrote:
> > All the traffic back and forth with the terminal happens in the
> > IOHandlerEditLine. We should be able to get our hands on the Debuggers
> > IOHandler and feed characters directly to it, and read the results. So we
> > should be able to write this kind of test by driving the debugger to
> > whatever state you need with SB API and then just run one command and get
> > the output string directly from the IOHandler. We should be able to then
> > scan that output for color codes. I don't think we need an external
> > process inspection tool to do this sort of thing.
> >
>
>
> Libedit expect to work with a real terminal, so to test the code that
> interacts with libedit (and there's more than 3 lines of that), you'll
> need something that can create a pty, and read and write characters to
> it, regardless of whether you drive the test through FileCheck or SB API.
>
> "creating a pty, and reading and writing to it" is pretty much the
> definition of pexpect.
>
> I am not saying either of this approaches can't be made to work, but I
> am not sure who is going to do it. I fear that we are shooting ourselves
> in the foot banning pexpect and then pushing patches without tests
> because "it's hard".
>
> Just for fun, I tried to write a test to check the coloring of the
> prompt via pexpect. It was _literally_ three lines long:
>
> def test_colored_prompt_comes_out_right(self):
> child = pexpect.spawn(lldbtest_config.lldbExec)
> child.expect_exact("(lldb) \x1b[1G\x1b[2m(lldb) \x1b[22m\x1b[8G")
>
>
> BTW: I am not proposing we spend heroic efforts trying to port pexpect
> 2.4 to python3. But I would consider using a newer version of pexpect to
> write tests ***where it makes sense to do so***. At least until someone
> comes up with a better (and not vapourware) alternative...
>
> pl
I found out that there are tests that effectively require
interactivity. Some of the lldb-mi ones are an example.
A common use-case is that of sending SIGTERM in a loop to make sure
`lldb-mi` doesn't crash and handle the signal correctly.
This functionality is really hard to replicate in lit _as is_.
Any ideas on how we could handle this case?
Thanks,
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
>
> On 21/02/2019 19:48, Ted Woodward wrote:
> >
> >
> >> -Original Message-
> >> From: lldb-dev On Behalf Of Pavel Labath
> >> via lldb-dev
> >> Sent: Thursday, February 21, 2019 8:35 AM
> >> To: Davide Italiano
> >> Cc: LLDB
> >> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
> >>
> >> On 21/02/2019 00:03, Davide Italiano wrote:
> >>> I found out that there are tests that effectively require
> >>> interactivity. Some of the lldb-mi ones are an example.
> >>> A common use-case is that of sending SIGTERM in a loop to make sure
> >>> `lldb-mi` doesn't crash and handle the signal correctly.
> >>>
> >>> This functionality is really hard to replicate in lit_as is_.
> >>> Any ideas on how we could handle this case?
> >>
> >> How hard is it to import a new version of pexpect which supports python3
> >> and
> >> stuff?
> >>
> >> I'm not sure how the situation is on darwin, but I'd expect (:P) that most
> >> linux
> >> systems either already have it installed, or have an easy way to do so. So
> >> we
> >> may not even be able to get away with just using the system one and
> >> skipping
> >> tests when it's not present.
> >>
> >> BTW, for lldb-mi I would actually argue that it should *not* use pexpect
> >> :D.
> >> Interactivity is one thing, and I'm very much in favour of keeping that
> >> ability,
> >> but pexpect is not a prerequisite for that. For me, the main advantage of
> >> pexpect is that it emulates a real terminal. However, lldb-mi does not need
> >> that stuff. It doesn't have any command line editing capabilities or
> >> similar. It's
> >> expecting to communicate with an IDE over a pipe, and that's it.
> >>
> >> Given that, it should be fairly easy to rewrite the lldb-mi tests to work
> >> on top
> >> of the standard python "subprocess" library. While we're doing that, we
> >> might
> >> actually fix some of the issues that have been bugging everyone in the
> >> lldb-mi
> >> tests. At least for me, the most annoying thing was that when lldb-mi
> >> fails to
> >> produce the expected output, the test does not fail immediately, but
> >> instead
> >> the implementation of self.expect("^whatever") waits until the timeout
> >> expires, optimistically hoping that it will find some output that match the
> >> pattern.
> >>
Pavel, I think yours is a really nice idea.
I'm no python expert, but I found out making the conversion is
relatively simple.
I propose a proof-of-concept API and implementation here:
https://gist.github.com/dcci/94a4936a227d9c7627b91ae9575b7b68
Comments appreciated! Once we agree on how this should look like, I do
recommend to have a new lldbMITest base class and incrementally start
moving the tests to it.
Once we're done, we can delete the old class.
Does this sound reasonable?
--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote:
>
>
>
> > On Feb 25, 2019, at 1:15 PM, Davide Italiano wrote:
> >
> > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
> >>
> >> On 21/02/2019 19:48, Ted Woodward wrote:
> >>>
> >>>
> -Original Message-
> From: lldb-dev On Behalf Of Pavel
> Labath
> via lldb-dev
> Sent: Thursday, February 21, 2019 8:35 AM
> To: Davide Italiano
> Cc: LLDB
> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
>
> On 21/02/2019 00:03, Davide Italiano wrote:
> > I found out that there are tests that effectively require
> > interactivity. Some of the lldb-mi ones are an example.
> > A common use-case is that of sending SIGTERM in a loop to make sure
> > `lldb-mi` doesn't crash and handle the signal correctly.
> >
> > This functionality is really hard to replicate in lit_as is_.
> > Any ideas on how we could handle this case?
>
> How hard is it to import a new version of pexpect which supports python3
> and
> stuff?
>
> I'm not sure how the situation is on darwin, but I'd expect (:P) that
> most linux
> systems either already have it installed, or have an easy way to do so.
> So we
> may not even be able to get away with just using the system one and
> skipping
> tests when it's not present.
>
> BTW, for lldb-mi I would actually argue that it should *not* use pexpect
> :D.
> Interactivity is one thing, and I'm very much in favour of keeping that
> ability,
> but pexpect is not a prerequisite for that. For me, the main advantage of
> pexpect is that it emulates a real terminal. However, lldb-mi does not
> need
> that stuff. It doesn't have any command line editing capabilities or
> similar. It's
> expecting to communicate with an IDE over a pipe, and that's it.
>
> Given that, it should be fairly easy to rewrite the lldb-mi tests to
> work on top
> of the standard python "subprocess" library. While we're doing that, we
> might
> actually fix some of the issues that have been bugging everyone in the
> lldb-mi
> tests. At least for me, the most annoying thing was that when lldb-mi
> fails to
> produce the expected output, the test does not fail immediately, but
> instead
> the implementation of self.expect("^whatever") waits until the timeout
> expires, optimistically hoping that it will find some output that match
> the
> pattern.
>
> >
> > Pavel, I think yours is a really nice idea.
> > I'm no python expert, but I found out making the conversion is
> > relatively simple.
> > I propose a proof-of-concept API and implementation here:
> >
> > https://gist.github.com/dcci/94a4936a227d9c7627b91ae9575b7b68
> >
> > Comments appreciated! Once we agree on how this should look like, I do
> > recommend to have a new lldbMITest base class and incrementally start
> > moving the tests to it.
> > Once we're done, we can delete the old class.
> >
> > Does this sound reasonable?
>
> What you are saying is that we would write the tests as Python tests in a way
> similar to how lldbtest.expect() look in the dotest.py tests, banking on
> synchronous mode taking care of all the synchronization? Are you thinking of
> doing this for all the remaining tests or only the ones where a command input
> depends on the result of a previous command?
>
I'm thinking to do this for all the remaining tests. Do you have any
concerns about this? (I'm aware your GSoC student introduced the `lit
lldb-mi` tests for a reason, I just don't know exactly what the reason
was).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
On Mon, Feb 25, 2019 at 1:57 PM Adrian Prantl wrote:
>
>
>
> > On Feb 25, 2019, at 1:40 PM, Davide Italiano wrote:
> >
> > On Mon, Feb 25, 2019 at 1:35 PM Adrian Prantl wrote:
> >>
> >>
> >>
> >>> On Feb 25, 2019, at 1:15 PM, Davide Italiano
> >>> wrote:
> >>>
> >>> On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
>
> On 21/02/2019 19:48, Ted Woodward wrote:
> >
> >
> >> -Original Message-
> >> From: lldb-dev On Behalf Of Pavel
> >> Labath
> >> via lldb-dev
> >> Sent: Thursday, February 21, 2019 8:35 AM
> >> To: Davide Italiano
> >> Cc: LLDB
> >> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
> >>
> >> On 21/02/2019 00:03, Davide Italiano wrote:
> >>> I found out that there are tests that effectively require
> >>> interactivity. Some of the lldb-mi ones are an example.
> >>> A common use-case is that of sending SIGTERM in a loop to make sure
> >>> `lldb-mi` doesn't crash and handle the signal correctly.
> >>>
> >>> This functionality is really hard to replicate in lit_as is_.
> >>> Any ideas on how we could handle this case?
> >>
> >> How hard is it to import a new version of pexpect which supports
> >> python3 and
> >> stuff?
> >>
> >> I'm not sure how the situation is on darwin, but I'd expect (:P) that
> >> most linux
> >> systems either already have it installed, or have an easy way to do
> >> so. So we
> >> may not even be able to get away with just using the system one and
> >> skipping
> >> tests when it's not present.
> >>
> >> BTW, for lldb-mi I would actually argue that it should *not* use
> >> pexpect :D.
> >> Interactivity is one thing, and I'm very much in favour of keeping
> >> that ability,
> >> but pexpect is not a prerequisite for that. For me, the main advantage
> >> of
> >> pexpect is that it emulates a real terminal. However, lldb-mi does not
> >> need
> >> that stuff. It doesn't have any command line editing capabilities or
> >> similar. It's
> >> expecting to communicate with an IDE over a pipe, and that's it.
> >>
> >> Given that, it should be fairly easy to rewrite the lldb-mi tests to
> >> work on top
> >> of the standard python "subprocess" library. While we're doing that,
> >> we might
> >> actually fix some of the issues that have been bugging everyone in the
> >> lldb-mi
> >> tests. At least for me, the most annoying thing was that when lldb-mi
> >> fails to
> >> produce the expected output, the test does not fail immediately, but
> >> instead
> >> the implementation of self.expect("^whatever") waits until the timeout
> >> expires, optimistically hoping that it will find some output that
> >> match the
> >> pattern.
> >>
> >>>
> >>> Pavel, I think yours is a really nice idea.
> >>> I'm no python expert, but I found out making the conversion is
> >>> relatively simple.
> >>> I propose a proof-of-concept API and implementation here:
> >>>
> >>> https://gist.github.com/dcci/94a4936a227d9c7627b91ae9575b7b68
> >>>
> >>> Comments appreciated! Once we agree on how this should look like, I do
> >>> recommend to have a new lldbMITest base class and incrementally start
> >>> moving the tests to it.
> >>> Once we're done, we can delete the old class.
> >>>
> >>> Does this sound reasonable?
> >>
> >> What you are saying is that we would write the tests as Python tests in a
> >> way similar to how lldbtest.expect() look in the dotest.py tests, banking
> >> on synchronous mode taking care of all the synchronization? Are you
> >> thinking of doing this for all the remaining tests or only the ones where
> >> a command input depends on the result of a previous command?
> >>
> >
> > I'm thinking to do this for all the remaining tests. Do you have any
> > concerns about this? (I'm aware your GSoC student introduced the `lit
> > lldb-mi` tests for a reason, I just don't know exactly what the reason
> > was).
>
> I think the reason was that for tests that don't need synchronization and
> have a static command input, writing a lit/FileCheck test is straightforward
> and easy. At the time I thought we could just rewrite *all* lldb-mi tests as
> FileCheck tests. If we do need a python mechanism anyway, however, I don't
> actually think that having two ways of writing tests is better; I'd rather
> have all tests in one place. Thankfully there shouldn't be that many tests,
> so we should be able to just convert all of them over to whatever format we
> eventually settle on.
> -- Adrian
>
Sounds good to me. Do you have a preference? I wanted to move away
from pexpect, so my preference was that of using `lit`.
I then realized that there are some functionalities that are not
really that easy to replicate in lit (e.g. sending signals, see my
previous mail), hence my vote for Python.subprocess (as Pavel
suggest
Re: [lldb-dev] RFC: Moving debug info parsing out of process
On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl via lldb-dev wrote: > > > > On Feb 25, 2019, at 10:21 AM, Zachary Turner via lldb-dev > wrote: > > Hi all, > > We've got some internal efforts in progress, and one of those would benefit > from debug info parsing being out of process (independently of whether or not > the rest of LLDB is out of process). > > There's a couple of advantages to this, which I'll enumerate here: > > It improves one source of instability in LLDB which has been known to be > problematic -- specifically, that debug info can be bad and handling this can > often be difficult and bring down the entire debug session. While other > efforts have been made to address stability by moving things out of process, > they have not been upstreamed, and even if they had I think we would still > want this anyway, for reasons that follow. > > Where do you draw the line between debug info and the in-process part of > LLDB? I'm asking because I have never seen the mechanical parsing of DWARF to > be a source of instability; We recently ran some testing and found lldb crashing while parsing DWARF (or, sometimes, failing to parse allegedly valid DWARF and returning some default constructed object and crashing later on). See, e.g. https://bugs.llvm.org/show_bug.cgi?id=40827 Qirun did his testing on Linux, FWIW. I would like to point out that the problems we ended up finding test some less stressed (but IMHO, equally important configurations, namely older compiler(s) [clang 3.8/clang 4.0/clang 5.0 etc..] and optimized code (-O1/-O2/-O3/-Os)]. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Build failure on Linux
I think this might have been fixed, try to pull. On Tue, Mar 5, 2019 at 3:10 AM Gábor Márton via lldb-dev wrote: > > Hi, > > On trunk I receive the following build error on Linux: > ../../git/llvm/tools/lldb/include/lldb/lldb-forward.h:181:7: note: > forward declaration of 'lldb_private::ProcessInstanceInfoList' > class ProcessInstanceInfoList; > ^ > ../../git/llvm/tools/lldb/source/Host/linux/Host.cpp:260:23: error: > member access into incomplete type > 'lldb_private::ProcessInstanceInfoList' > return process_infos.GetSize(); > > When I put back the below line into linux/Host.cpp > #include "lldb/Target/Process.h" > the error is gone. > > Based on this info, this commit could be blamed: > commit e9a520afd257bf71f7ead0d33e4734008abf690c > Author: Zachary Turner > AuthorDate: Mon Mar 4 21:51:03 2019 + > Commit: Zachary Turner > CommitDate: Mon Mar 4 21:51:03 2019 + > > Move ProcessInfo from Host to Utility. > > Could you please take a look? > > Thanks, > Gabor > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Flaky test on GreenDragon?
On Thu, Mar 7, 2019 at 7:04 AM Gábor Márton via lldb-dev wrote: > > Hi guys, > > I've seen that recently the test > lldb-Suite.macosx/queues.TestQueues.py fails non-deterministically. > > E.g. > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21271/testReport/ > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21244/testReport/ > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21229/testReport/ > > This is causing some inconvenience for us, e.g. our last commit > triggered a build and we thought we broke something but the next build > was successful without any action on our part. > > Could we disable this flaky test? Or is there some other solution? > +Fred, who checked in a fix for that recently https://reviews.llvm.org/D58912 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON
I'm in favor of this. FWIW, I will be surprised if lldb works at all with that option. On Thu, Mar 7, 2019 at 10:28 AM Adrian McCarthy via lldb-dev wrote: > > We have a build option to build LLDB without Python. This option is > automatically set if Cmake can't find or "validate" your Python distribution. > > Since LLDB is rarely built with this option, nobody discovers when this > configuration breaks. For example, if you try it today, you'll get a handful > of missing symbol errors because their declarations are #if'ed out but other > code still references them. > > I'm proposing eliminating this option and fixing the validation of the Python > distribution in LLDBConfig.cmake. > > If you believe LLDB_DISABLE_PYTHON is still useful, please speak up, and I'll > instead look at fixing the existing build problems. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC]The future of pexpect
After discussing this privately with Pavel we decided to try updating
pexpect instead.
On Tue, Feb 26, 2019 at 4:42 AM Pavel Labath wrote:
>
> On 25/02/2019 22:15, Davide Italiano wrote:
> > On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote:
> >>
> >> On 21/02/2019 19:48, Ted Woodward wrote:
> >>>
> >>>
> -Original Message-
> From: lldb-dev On Behalf Of Pavel
> Labath
> via lldb-dev
> Sent: Thursday, February 21, 2019 8:35 AM
> To: Davide Italiano
> Cc: LLDB
> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
>
> On 21/02/2019 00:03, Davide Italiano wrote:
> > I found out that there are tests that effectively require
> > interactivity. Some of the lldb-mi ones are an example.
> > A common use-case is that of sending SIGTERM in a loop to make sure
> > `lldb-mi` doesn't crash and handle the signal correctly.
> >
> > This functionality is really hard to replicate in lit_as is_.
> > Any ideas on how we could handle this case?
>
> How hard is it to import a new version of pexpect which supports python3
> and
> stuff?
>
> I'm not sure how the situation is on darwin, but I'd expect (:P) that
> most linux
> systems either already have it installed, or have an easy way to do so.
> So we
> may not even be able to get away with just using the system one and
> skipping
> tests when it's not present.
>
> BTW, for lldb-mi I would actually argue that it should *not* use pexpect
> :D.
> Interactivity is one thing, and I'm very much in favour of keeping that
> ability,
> but pexpect is not a prerequisite for that. For me, the main advantage of
> pexpect is that it emulates a real terminal. However, lldb-mi does not
> need
> that stuff. It doesn't have any command line editing capabilities or
> similar. It's
> expecting to communicate with an IDE over a pipe, and that's it.
>
> Given that, it should be fairly easy to rewrite the lldb-mi tests to
> work on top
> of the standard python "subprocess" library. While we're doing that, we
> might
> actually fix some of the issues that have been bugging everyone in the
> lldb-mi
> tests. At least for me, the most annoying thing was that when lldb-mi
> fails to
> produce the expected output, the test does not fail immediately, but
> instead
> the implementation of self.expect("^whatever") waits until the timeout
> expires, optimistically hoping that it will find some output that match
> the
> pattern.
>
> >
> > Pavel, I think yours is a really nice idea.
> > I'm no python expert, but I found out making the conversion is
> > relatively simple.
> > I propose a proof-of-concept API and implementation here:
> >
> > https://gist.github.com/dcci/94a4936a227d9c7627b91ae9575b7b68
> >
> > Comments appreciated! Once we agree on how this should look like, I do
> > recommend to have a new lldbMITest base class and incrementally start
> > moving the tests to it.
> > Once we're done, we can delete the old class.
> >
> > Does this sound reasonable?
> >
> > --
> > Davide
> >
>
> Sounds great. Let's ship it. :)
>
> pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Trouble running Python tests on Windows
+ Stella/Pavel On Fri, May 31, 2019 at 8:42 AM Alexandre Ganea via lldb-dev wrote: > > Hi, > > > > I can’t seem to run the lldb python tests on my Windows 10 setup. I use the > following cmd-line to generate: > > > > cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release > -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld > -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang -DLLVM_TOOL_LLD_BUILD=true > -DLLVM_TOOL_CLANG_BUILD=true -DLLVM_ENABLE_PDB=true > -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_EXTERNAL_LLDB_SOURCE_DIR=f:/svn/lldb > -DLLVM_TOOL_LLDB_BUILD=true > -DPYTHON_HOME="C:\Users\aganea\AppData\Local\Programs\Python\Python37" > > > > Followed by: ninja check-all, which ends up in a bunch of: > > > > TEST 'lldb-Suite :: > tools/lldb-server/TestAppleSimulatorOSType.py' FAILED > > Unable to find 'RESULT: PASSED' in dotest output: > > > > lldb version 9.0.0 (https://aga...@llvm.org/svn/llvm-project/lldb/trunk > revision 361826) > > clang revision 361826 > > llvm revision 361826 > > LLDB library dir: F:\svn\buildninja\bin > > LLDB import library dir: F:\svn\buildninja\bin\..\lib > > Traceback (most recent call last): > > File "F:/svn/lldb/test/dotest.py", line 7, in > > lldbsuite.test.run_suite() > > File "F:\svn\lldb\packages\Python\lldbsuite\test\dotest.py", line 1243, in > run_suite > > import lldb > > File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1500, in > > > class SBAddress(object): > > File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1675, in > SBAddress > > __swig_getmethods__["module"] = GetModule > > NameError: name '__swig_getmethods__' is not defined > > > > Swig 4.0.0 is there in %PATH%. I’m using MSVC 19.16.27031.1 for compiling. > I’ve tried with Clang 8.0, same issues. > > Any idea on what could be missing? > > > > Thanks in advance! > > Alex. > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Removing lldb-mi
On Mon, Jul 1, 2019 at 3:21 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really > like to keep it! 😊 > > > Is there any reason why this can't be a downstream project? Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Removing lldb-mi
On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev < lldb-dev@lists.llvm.org> wrote: > We're using it with Eclipse and Eclipse based product, so I'd like to keep > as well! :-)... > > Zdenek > I do understand that there's desire from people to keep this around (from an user perspective), but I guess this fundamentally misses Jonas' original mail point. lldb-mi has been unmaintained for a long time (at least the past two years from what I can tell), and we tried to use it in emacs without success. It has never been a priority for many of the parties putting effort in lldb and I'm under the impression the situation won't change in the foreseeable future. Unless somebody steps up as maintainer I don't think there's a lot of future for the tool. Maybe a good compromise would be that of having lldb-mi living in a separate repo somewhere on GitHub, as it only uses the SBAPI, which is public and set in stone? -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Who sets the 10-minute timeouts?
On Wed, Aug 14, 2019 at 11:27 AM Adrian McCarthy via lldb-dev wrote: > > A recent change is causing several LLDB tests on Windows to fail and several > more to time out, which I intend to look into. > > It appears the timeout period is set to 600 seconds (10 minutes), which seems > excessive and causes the Windows build bot to spend lots of time waiting. > (e.g., > http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio) > > Is there a reason why the timeouts are set that long? What would be a > reasonable value? > It's just a number picked after some observation of the testsuite behaviour. Historically there were some tests taking 3-5minutes to run to I think the rationale was (2*[max_duration_single_test]), but lots of things changed so maybe can be revisited. Also, I'm under the impression given the test suite uses lit, individual bots can override the value. -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Restructuring the (command) tests
On Fri, Aug 30, 2019 at 1:44 AM Raphael “Teemperor” Isemann via
lldb-dev wrote:
>
> Hi all,
>
> I have to admit I’m getting a bit confused lately where to put tests.
> Especially for testing LLDB commands it’s not obvious where to put files as
> we test some commands directly in the top-level test folder (e.g. quit, help,
> settings), some are in /functionalities with a _command suffix (e.g. target),
> some are in /functionalities without any suffix (e.g. register), some tests
> are split by subcommand (process, frame) and some are in the top-level folder
> with the _command prefix (e.g. expression). This makes it hard to figure out
> where to find or create tests for specific commands. Also setting a
> LIT_FILTER for jus testing CommandObject* changes is not possible.
>
> I would propose we restructure at least the command tests into
> “test/commands/${command_name}/${subcommand_name_or_functionality}/“ such as
> “test/commands/process/launch”. The LIT_FILTER for these things would be
> “commands/“.
>
> I don’t see any disadvantages from this as
> * downstreams usually doesn’t fiddle around with the existing tests, so there
> should hopefully be no merge conflicts from this.
> * git blame can handle this change as we only move files/directories and
> don’t touch their contents.
> * it’s very little work to actually do this.
>
> I’m not sure if there is a need to restructure any other tests but I think if
> there are no objections in this thread, then I assume everyone can just take
> a few seconds and restructure their own tests.
>
+1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Offline build bots
Presumably Pavel and Michal (both cc'ed).
On Fri, Oct 11, 2019 at 3:06 PM António Afonso via lldb-dev
wrote:
>
> Hi,
>
> All the *nix build bots (lldb-x86_86-{debian,fedora}, netbsd-amd64) have been
> offline for a while now. Some as far as July 12.
> I’m not sure if this is being tracked or whom to contact about this.
>
> Thank you.
> - Afonso
>
> --
> Best regards,
> António Afonso
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery
On Wed, Oct 30, 2019 at 11:52 AM Jim Ingham via lldb-dev
wrote:
>
> Except of course without the comment markers...
>
> > On Oct 30, 2019, at 11:36 AM, Jim Ingham wrote:
> >
> > Anyway, another way to do this would be something like:
> >
> > #if (${LLVM_DEFAULT_TARGET_TRIPLE})
> > string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> > "${LLVM_DEFAULT_TARGET_TRIPLE}")
> > #else()
> > # set(LLDB_DEBUGSERVER_ARCH "")
> > #endif()
> >
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] https://reviews.llvm.org/D69273
Thanks for the explanation. + Pavel & Adrian.
On Thu, Oct 31, 2019 at 12:51 PM Jim Ingham via lldb-dev
wrote:
>
> It looks like this change is causing problems with swift. I was talking a
> little bit with Davide about this and it seems like it wasn't obvious how
> this was designed to work. So here's what this was intended to do (apologies
> if this is at too basic a level and the issue was something deeper I missed,
> but anyway this might get us started...)
>
> The lldb ValueObject system supports two fairly different kinds of values,
> live and frozen.
>
> The classic example of a live ValueObject is ValueObjectVariable. That
> ValueObject is backed by an entity in the target, and knows when that entity
> is valid and not. So it can always try to do "UpdateValueIfNeeded" and that
> will always return good values. However, there's on complication with this,
> which is that we also want ValueObjectVariable to be able to answer
> "IsChanged". That's so in a UI you can mark values that change over a step
> in red, which is very helpful for following along in a debugging session. So
> you have to copy the values into host memory, in order to have something to
> compare against when you stop again. That's why there's this slightly
> complex dance between host and target memory for the live ValueObjects.
>
> The example of a frozen object is the ValueObjectConstResult that is returned
> from expression evaluation. That value is fixed to a StopID, so the backing
> entity is only known to be good at that stop id. This is implemented by
> copying the value into Host memory and fetching it from there when requested.
>
> The use case for this is for people like me who have a bad memory. So I can
> stop somewhere and do:
>
> (lldb) expr foo
> struct baz $1 = {
> bar = 20
> }
>
> Then later on when I forget what foo.bar was at that time, I can do:
>
> (lldb) expr $1.bar
> bar = 20
>
> At a first approximation, this leads to the statement that ConstValues should
> fetch what they fetch when made, and then not offer any information that
> wasn't gathered when the variable was fetched, and you certainly don't ever
> want these values to be updated.
>
> A little complication arises because I might do:
>
> (lldb) expr foo_which_has_a_pointer
> $1 = ...
> (lldb) expr *$1->the_pointer
>
> If the StopID is the same between the first and second evaluation, then you
> should follow the pointer into target memory and fetch the value. But if the
> StopID has changed, then trying to dereference a pointer should be an error.
> After all, you are now accessing an incoherent object, and if you try to do
> anything fancier with it than just print some memory (like asking the Swift
> Language Runtime what this value happens to be) you are very likely to get
> into trouble.
>
> So it's clear we need two different behaviors w.r.t. how we treat live or
> frozen values. Pavel's change was addressing a failure in ValueObjectChild,
> and the solution was to move the ValueObjectVariable behavior up to the
> ValueObject level. But then that means that ValueObjectConstResults are no
> longer obeying the ConstResult rules.
>
> But it seems like the problem really is that we have only one
> ValueObjectChild class, but child value objects can either be live or frozen,
> depending on the nature of their Root ValueObject. And this is made a little
> more complicated by the fact that frozen values only freeze when the stop ID
> changes.
>
> Jim
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] https://reviews.llvm.org/D69273
On Thu, Oct 31, 2019 at 1:06 PM Pavel Labath via lldb-dev wrote: > > (Just writing to say that tomorrow is a public holiday in most of > Europe, so I wont be able to meaningfully reply to this until > monday/tuesday. But if, in the mean time, you want to revert this, or > just limit the scope of that patch somehow, then that's fine with me.) > I don't see this as an urgent revert. We just cherry-picked the change in our branches and realized that it was creating some problems, so we raised the issue and started the discussion. Definitely it can wait a day or two. Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Saving and restoring STDIN in the ScriptInterpreter
Hi Pavel, Jonas,
I was trying to reduce a bug through c-reduce, so I decided to write a SBAPI
script to make it easier.
I did find out, that after the first iteration, the reduction gets stuck
forever.
I sampled the process and I saw the following (trimmed for readability).
Call graph:
[…]
8455
lldb_private::CommandInterpreter::GetScriptInterpreter(bool) (in _lldb.so) +
84 [0x111aff826]
8455
lldb_private::PluginManager::GetScriptInterpreterForLanguage(lldb::ScriptLanguage,
lldb_private::CommandInterpreter&) (in _lldb.so) + 99 [0x111a1efcf]
8455
lldb_private::ScriptInterpreterPython::CreateInstance(lldb_private::CommandInterpreter&)
(in _lldb.so) + 26 [0x111d128f4]
8455
std::__1::shared_ptr
std::__1::shared_ptr::make_shared(lldb_private::CommandInterpreter&&&)
(in _lldb.so) + 72 [0x111d1b976]
8455
lldb_private::ScriptInterpreterPython::ScriptInterpreterPython(lldb_private::CommandInterpreter&)
(in _lldb.so) + 353 [0x111d11ff3]
8455
lldb_private::ScriptInterpreterPython::InitializePrivate() (in _lldb.so) + 494
[0x111d12594]
8455
(anonymous namespace)::InitializePythonRAII::~InitializePythonRAII() (in
_lldb.so) + 146 [0x111d1b446]
8455
lldb_private::TerminalState::Restore() const (in _lldb.so) + 74 [0x111ac8268]
8455 tcsetattr (in libsystem_c.dylib) + 110 [0x7fff7b95b585]
8455 ioctl (in libsystem_kernel.dylib) + 151 [0x7fff7ba19b44]
8455 __ioctl (in libsystem_kernel.dylib) + 10 [0x7fff7ba19b5a]
It looks like lldb gets stuck forever in `tcsetattr()`, and there are no other
threads waiting so it’s not entirely obvious to me why it’s waiting there.
I was never able to reproduce this with an interactive session, I suspect this
is somehow related to the fact that c-reduce spawns a thread in the background,
hence it doesn’t have a TTY associated.
I looked at the code that does this, and I wasn’t really able to find a reason
why we need to do this work. Jim thinks it might have been needed historically.
`git blame` doesn’t really help that much either. If I remove the code,
everything still passes and it’s functional, but before moving forward with
this I would like to collect your opinions.
$ git diff
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index ee94a183e0d..c53b3bd0fb6 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -224,10 +224,6 @@ struct InitializePythonRAII {
public:
InitializePythonRAII()
: m_gil_state(PyGILState_UNLOCKED), m_was_already_initialized(false) {
-// Python will muck with STDIN terminal state, so save off any current TTY
-// settings so we can restore them.
-m_stdin_tty_state.Save(STDIN_FILENO, false);
-
InitializePythonHome();
#ifdef LLDB_USE_LIBEDIT_READLINE_COMPAT_MODULE
@@ -271,8 +267,6 @@ public:
// We initialized the threads in this function, just unlock the GIL.
PyEval_SaveThread();
}
-
-m_stdin_tty_state.Restore();
}
private:___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
