[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment. > Removal of functionality - The lit test suite no longer respects > LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no more > support for gcc, but nobody was using this anyway (note: The functionality is > still there for the dotest suite, just not the lit test suite). The "nobody is using this part" of that statement is just not true. On green dragon, we have two bots that use LLDB_TEST_C_COMPILER / LLDB_TEST_CXX_COMPILER that run the LLDB testsuite against older versions of clang: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-6.0.1/ https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment. We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER from the cmake files along with this change, otherwise, people will still expect them to work. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment. There is also this bot that does something similar with even more compilers, including gcc: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242 Do you happen to know who maintains it? https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment. In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER from > the cmake files along with this change, otherwise, people will still expect > them to work. That would not be a good idea. There are several bots that are using these flags. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment. In https://reviews.llvm.org/D54567#122, @aprantl wrote: > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER from > > the cmake files along with this change, otherwise, people will still expect > > them to work. > > > That would not be a good idea. There are several bots that are using these > flags. The change that Zachary is making is removing their usage, so after his change they would not do anything. If he ends up committing this change, these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment.
In https://reviews.llvm.org/D54567#1299982, @aprantl wrote:
> > Removal of functionality - The lit test suite no longer respects
> > LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
> > more support for gcc, but nobody was using this anyway (note: The
> > functionality is still there for the dotest suite, just not the lit test
> > suite).
>
> The "nobody is using this part" of that statement is just not true.
>
> On green dragon, we have two bots that use LLDB_TEST_C_COMPILER /
> LLDB_TEST_CXX_COMPILER that run the LLDB testsuite against older versions of
> clang:
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-6.0.1/
It's possible I didn't make this part clear enough. I didn't mean that nobody
is using `LLDB_TEST_C_COMPILER`, I meant that nobody is using it **in order to
compile inferiors with gcc**. There is also a dichotomy between what happens
for the dotest suite and the lit suite. For the dotest suite,
`LLDB_TEST_C(XX)_COMPILER` are still respected, this patch hasn't changed that.
It has only changed the behavior of running tests in
`lldb/lit/{Breakpoint/Expr/Modules/Quit/Settings/SymbolFile/tools}`. Even for
those tests, it is still possible to use a not-just-built clang, just that
instead of specifying `LLDB_TEST_C(XX)_COMPILER`, you now specify
`LLDB_LIT_TOOLS_DIR`.
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment. In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > from the cmake files along with this change, otherwise, people will still > > > expect them to work. > > > > > > That would not be a good idea. There are several bots that are using these > > flags. > > > The change that Zachary is making is removing their usage, so after his > change they would not do anything. If he ends up committing this change, > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. Perhaps I'm misunderstanding something. My primary point is that we need a way to run configure which C and C++ compiler is used to compile the tests in LLDB testsuite. As long as this is still possible, I'm happy. We discussed previously that we might want to separate tests that exercise different compilers from tests that exercise core functionality of LLDB and perhaps the `lit/` vs. the `packages/` subdirectories is where we want to draw this line, and only keep the configurability of the compiler for the tests in the `packages/` directory. But it isn't clear to me that that is where this is going either. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > from the cmake files along with this change, otherwise, people will still > > > expect them to work. > > > > > > That would not be a good idea. There are several bots that are using these > > flags. > > > The change that Zachary is making is removing their usage, so after his > change they would not do anything. If he ends up committing this change, > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. The flags are still needed for (and used by) the dotest suite, I didn't change that part. Normally you run that suite by doing `ninja check-lldb`, in which case it never goes through these lit files to begin with. But they will also run as part of `ninja check-lldb-lit`, but that lit configuration file totally overrides everything in the parent one, so nothing in this patch should have any effect on that. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#128, @aprantl wrote: > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > > from the cmake files along with this change, otherwise, people will > > > > still expect them to work. > > > > > > > > > That would not be a good idea. There are several bots that are using > > > these flags. > > > > > > The change that Zachary is making is removing their usage, so after his > > change they would not do anything. If he ends up committing this change, > > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. > > > Perhaps I'm misunderstanding something. My primary point is that we need a > way to run configure which C and C++ compiler is used to compile the tests in > LLDB testsuite. As long as this is still possible, I'm happy. > > We discussed previously that we might want to separate tests that exercise > different compilers from tests that exercise core functionality of LLDB and > perhaps the `lit/` vs. the `packages/` subdirectories is where we want to > draw this line, and only keep the configurability of the compiler for the > tests in the `packages/` directory. But it isn't clear to me that that is > where this is going either. I always have trouble making sense of the Greendragon bots. Starting from this page: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ What do I need to click on to get the equivalent of this: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31244/steps/test6/logs/stdio https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54476: [CMake] Streamline code signing for debugserver
labath added inline comments. Comment at: tools/debugserver/source/CMakeLists.txt:101 +option(LLDB_NO_DEBUGSERVER "Delete debugserver after building it, and don't try to codesign it" OFF) +option(LLDB_USE_SYSTEM_DEBUGSERVER "Neither build nor codesign debugserver. Use the system's debugserver instead (Darwin only)." OFF) + sgraenitz wrote: > JDevlieghere wrote: > > Should we emit and error if these variables are in an inconsistent state, > > e.g. when both are set? > Yes, could do that. Alternatively, we could make this a single tri-state variable. `LLDB_DEBUGSERVER_MODE=OFF|SYSTEM|TREE` or something ? https://reviews.llvm.org/D54476 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment.
In https://reviews.llvm.org/D54567#127, @zturner wrote:
> It's possible I didn't make this part clear enough. I didn't mean that
> nobody is using `LLDB_TEST_C_COMPILER`, I meant that nobody is using it **in
> order to compile inferiors with gcc**. There is also a dichotomy between
> what happens for the dotest suite and the lit suite. For the dotest suite,
> `LLDB_TEST_C(XX)_COMPILER` are still respected, this patch hasn't changed
> that. It has only changed the behavior of running tests in
> `lldb/lit/{Breakpoint/Expr/Modules/Quit/Settings/SymbolFile/tools}`. Even
> for those tests, it is still possible to use a not-just-built clang, just
> that instead of specifying `LLDB_TEST_C(XX)_COMPILER`, you now specify
> `LLDB_LIT_TOOLS_DIR`.
Thanks, that makes more sense to me! (I'm still not sure that it is correct
though: cf.
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242)
In https://reviews.llvm.org/D54567#129, @zturner wrote:
> The flags are still needed for (and used by) the dotest suite, I didn't
> change that part. Normally you run that suite by doing `ninja check-lldb`,
> in which case it never goes through these lit files to begin with. But they
> will also run as part of `ninja check-lldb-lit`, but that lit configuration
> file totally overrides everything in the parent one, so nothing in this patch
> should have any effect on that.
Do we document the fact that the two testsuites behave differently in this
respect? I'm worried that developers that aren't aware of that difference will
test new functionality only with a LIT test out of convenience (because they
are more familiar with this style from LLVM) and that that will erode our test
coverage on other or older compilers over time.
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment. In https://reviews.llvm.org/D54567#130, @zturner wrote: > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ > > What do I need to click on to get the equivalent of this: > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31244/steps/test6/logs/stdio Click on a recent build and then on "Console Output". Here is one from yesterday (we are upgrading the machines right now and temporarily broke the build): http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/1356/consoleFull https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment. In https://reviews.llvm.org/D54567#129, @zturner wrote: > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > > from the cmake files along with this change, otherwise, people will > > > > still expect them to work. > > > > > > > > > That would not be a good idea. There are several bots that are using > > > these flags. > > > > > > The change that Zachary is making is removing their usage, so after his > > change they would not do anything. If he ends up committing this change, > > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. > > > The flags are still needed for (and used by) the dotest suite, I didn't > change that part. Normally you run that suite by doing `ninja check-lldb`, > in which case it never goes through these lit files to begin with. But they > will also run as part of `ninja check-lldb-lit`, but that lit configuration > file totally overrides everything in the parent one, so nothing in this patch > should have any effect on that. I think this is actually confusing - there are two ways to specify compilers for the lldb test suite at cmake time: 1. Via LLDB_TEST_USE_CUSTOM_C_COMPILER and friends 2. Via LLDB_TEST_USER_ARGS As far as I can tell, the ubuntu 14 bot that @aprantl pointed to uses the LLDB_TEST_USER_ARGS path. I *think* the green dragon bots also use the LLDB_TEST_USER_ARGS and AFAIK it's the only way gcc is ever specified for the tests. If the LLDB_TEST_USE_CUSTOM_C_COMPILER and friends are not used for the lit tests, I don't think we need them for the suite tests. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment. In https://reviews.llvm.org/D54567#1300030, @aprantl wrote: > In https://reviews.llvm.org/D54567#130, @zturner wrote: > > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ > > > > What do I need to click on to get the equivalent of this: > > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31244/steps/test6/logs/stdio > > > Click on a recent build and then on "Console Output". Here is one from > yesterday (we are upgrading the machines right now and temporarily broke the > build): > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/1356/consoleFull Ok, now I see it: python /opt/llvm/zorg/zorg/jenkins//build.py --assertions --cmake-type=Release --cmake-flag=-DLLVM_TARGETS_TO_BUILD=X86 --cmake-flag=-DLLDB_TEST_USE_CUSTOM_C_COMPILER=On --cmake-flag=-DLLDB_TEST_USE_CUSTOM_CXX_COMPILER=On --cmake-flag=-DLLDB_TEST_C_COMPILER=/Users/buildslave/jenkins/workspace/lldb-cmake-clang-5.0.2/lldb-build/history/clang-5.0.2/bin/clang --cmake-flag=-DLLDB_TEST_CXX_COMPILER=/Users/buildslave/jenkins/workspace/lldb-cmake-clang-5.0.2/lldb-build/history/clang-5.0.2/bin/clang++ --dotest-flag=--skip-category --dotest-flag=gmodules lldb-cmake https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment.
In https://reviews.llvm.org/D54567#1300028, @aprantl wrote:
> In https://reviews.llvm.org/D54567#127, @zturner wrote:
>
> > It's possible I didn't make this part clear enough. I didn't mean that
> > nobody is using `LLDB_TEST_C_COMPILER`, I meant that nobody is using it
> > **in order to compile inferiors with gcc**. There is also a dichotomy
> > between what happens for the dotest suite and the lit suite. For the
> > dotest suite, `LLDB_TEST_C(XX)_COMPILER` are still respected, this patch
> > hasn't changed that. It has only changed the behavior of running tests in
> > `lldb/lit/{Breakpoint/Expr/Modules/Quit/Settings/SymbolFile/tools}`. Even
> > for those tests, it is still possible to use a not-just-built clang, just
> > that instead of specifying `LLDB_TEST_C(XX)_COMPILER`, you now specify
> > `LLDB_LIT_TOOLS_DIR`.
>
>
> Thanks, that makes more sense to me! (I'm still not sure that it is correct
> though: cf.
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242)
FWIW this bot appears unmaintained. I can try to contact the owner though.
That aside, it looks like this bot directly runs `dotest.py` and constructs the
command line itself
(http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242/steps/test1/logs/stdio).
The first few lines of output in the stdio look like this:
++ dotest_args=()
++ dotest_args+=(-A "$arch" -C "$compiler")
++ dotest_args+=(-v -s "logs-$cc_log-$arch")
++ dotest_args+=(-u CXXFLAGS -u CFLAGS)
++ dotest_args+=(--env ARCHIVER=ar --env OBJCOPY=objcopy)
++ appendCommonArgs
++ dotest_args+=(--executable "$buildDir/bin/lldb")
++ dotest_args+=(--filecheck "$buildDir/bin/FileCheck")
++ for c in '"gdb-remote packets"' '"lldb all"'
++ dotest_args+=(--channel "$c")
++ for c in '"gdb-remote packets"' '"lldb all"'
++ dotest_args+=(--channel "$c")
++ for c in '"${categories[@]}"'
++ case "$c" in
++ dotest_args+=(--skip-category "${c#-}")
++ for c in '"${categories[@]}"'
++ case "$c" in
In that case, I don't think it relies on `LLDB_TEST_C_COMPILER` etc. It
definitely does compile inferiors with gcc, but it seems to do it use its own
custom scripts to make all this work.
>
>
> In https://reviews.llvm.org/D54567#129, @zturner wrote:
>
>> The flags are still needed for (and used by) the dotest suite, I didn't
>> change that part. Normally you run that suite by doing `ninja check-lldb`,
>> in which case it never goes through these lit files to begin with. But they
>> will also run as part of `ninja check-lldb-lit`, but that lit configuration
>> file totally overrides everything in the parent one, so nothing in this
>> patch should have any effect on that.
>
>
> Do we document the fact that the two testsuites behave differently in this
> respect? I'm worried that developers that aren't aware of that difference
> will test new functionality only with a LIT test out of convenience (because
> they are more familiar with this style from LLVM) and that that will erode
> our test coverage on other or older compilers over time.
For older versions of clang, I think it's still just as easy to run the test
suite with that compiler as opposed to the just built compiler. Just stick
your clang binaries in a folder and pass `-DLLDB_LIT_TOOLS_DIR` (we can change
the variable names if anyone has ideas for better / clearer names). So any
bots which are currently running tests with old versions of clang can pass this
flag and that will still provide coverage with older compiler versions.
For other compilers entirely, it would be nice to come up with a solution. I'd
like to eventually get rid of the `check-lldb` target (which constructs a
`dotest` command line inside of CMake and just runs it directly, bypassing all
of this) and if that ever happens, we could get rid of the parallel variables,
but it would also necessitate solving the other-compilers problem.
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#1300031, @stella.stamenova wrote: > In https://reviews.llvm.org/D54567#1300030, @aprantl wrote: > > > In https://reviews.llvm.org/D54567#130, @zturner wrote: > > > > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ > > > > > > What do I need to click on to get the equivalent of this: > > > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31244/steps/test6/logs/stdio > > > > > > Click on a recent build and then on "Console Output". Here is one from > > yesterday (we are upgrading the machines right now and temporarily broke > > the build): > > > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/1356/consoleFull > > > Ok, now I see it: > > python /opt/llvm/zorg/zorg/jenkins//build.py --assertions > --cmake-type=Release --cmake-flag=-DLLVM_TARGETS_TO_BUILD=X86 > --cmake-flag=-DLLDB_TEST_USE_CUSTOM_C_COMPILER=On > --cmake-flag=-DLLDB_TEST_USE_CUSTOM_CXX_COMPILER=On > --cmake-flag=-DLLDB_TEST_C_COMPILER=/Users/buildslave/jenkins/workspace/lldb-cmake-clang-5.0.2/lldb-build/history/clang-5.0.2/bin/clang > > --cmake-flag=-DLLDB_TEST_CXX_COMPILER=/Users/buildslave/jenkins/workspace/lldb-cmake-clang-5.0.2/lldb-build/history/clang-5.0.2/bin/clang++ > --dotest-flag=--skip-category --dotest-flag=gmodules lldb-cmake > The equivalent command line after this patch would be to keep all of the `-DLLDB_TEST_XXX` variables, but to add one more that says `-DLLDB_LIT_TOOLS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake-clang-5.0.2/lldb-build/history/clang-5.0.2/bin`. It will search this path first when looking for `clang` and `clang++` for all of the LLDB tests, but still use the `_CXX_COMPILER` and `_C_COMPILER` paths for the `LLDB-Suite` tests. At least, that's the intention. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#1300029, @stella.stamenova wrote: > In https://reviews.llvm.org/D54567#129, @zturner wrote: > > > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > > > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > > > from the cmake files along with this change, otherwise, people will > > > > > still expect them to work. > > > > > > > > > > > > That would not be a good idea. There are several bots that are using > > > > these flags. > > > > > > > > > The change that Zachary is making is removing their usage, so after his > > > change they would not do anything. If he ends up committing this change, > > > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > > > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. > > > > > > The flags are still needed for (and used by) the dotest suite, I didn't > > change that part. Normally you run that suite by doing `ninja check-lldb`, > > in which case it never goes through these lit files to begin with. But > > they will also run as part of `ninja check-lldb-lit`, but that lit > > configuration file totally overrides everything in the parent one, so > > nothing in this patch should have any effect on that. > > > I think this is actually confusing - there are two ways to specify compilers > for the lldb test suite at cmake time: > > 1. Via LLDB_TEST_USE_CUSTOM_C_COMPILER and friends > 2. Via LLDB_TEST_USER_ARGS > > As far as I can tell, the ubuntu 14 bot that @aprantl pointed to uses the > LLDB_TEST_USER_ARGS path. I *think* the green dragon bots also use the > LLDB_TEST_USER_ARGS and AFAIK it's the only way gcc is ever specified for the > tests. If the LLDB_TEST_USE_CUSTOM_C_COMPILER and friends are not used for > the lit tests, I don't think we need them for the suite tests. The ubuntu bot doesn't use the cmake configuration at all. It runs the test in 6 different configurations, but CMake gives you exactly 1 configuration, so it can't do things that way. AFAICT the Ubuntu bot adrian linked has 6 different shell scripts that manually construct the proper `dotest` command lines. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
aprantl added a comment.
In https://reviews.llvm.org/D54567#1300035, @zturner wrote:
> In https://reviews.llvm.org/D54567#1300028, @aprantl wrote:
>
> > In https://reviews.llvm.org/D54567#127, @zturner wrote:
> >
> > > It's possible I didn't make this part clear enough. I didn't mean that
> > > nobody is using `LLDB_TEST_C_COMPILER`, I meant that nobody is using it
> > > **in order to compile inferiors with gcc**. There is also a dichotomy
> > > between what happens for the dotest suite and the lit suite. For the
> > > dotest suite, `LLDB_TEST_C(XX)_COMPILER` are still respected, this patch
> > > hasn't changed that. It has only changed the behavior of running tests
> > > in `lldb/lit/{Breakpoint/Expr/Modules/Quit/Settings/SymbolFile/tools}`.
> > > Even for those tests, it is still possible to use a not-just-built clang,
> > > just that instead of specifying `LLDB_TEST_C(XX)_COMPILER`, you now
> > > specify `LLDB_LIT_TOOLS_DIR`.
> >
> >
> > Thanks, that makes more sense to me! (I'm still not sure that it is correct
> > though: cf.
> > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242)
>
>
> FWIW this bot appears unmaintained. I can try to contact the owner though.
> That aside, it looks like this bot directly runs `dotest.py` and constructs
> the command line itself
> (http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/31242/steps/test1/logs/stdio).
> The first few lines of output in the stdio look like this:
Thanks for checking! It would be unfortunate if it is unmaintained, because
bots like that one are a very valuable sanity-check against symmetric bugs,
where, e.g., someone misinterprets the DWARF spec and then implements the same
wrong behavior in both clang and LLDB.
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#1300029, @stella.stamenova wrote: > In https://reviews.llvm.org/D54567#129, @zturner wrote: > > > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote: > > > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote: > > > > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote: > > > > > > > > > We should also remove LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER > > > > > from the cmake files along with this change, otherwise, people will > > > > > still expect them to work. > > > > > > > > > > > > That would not be a good idea. There are several bots that are using > > > > these flags. > > > > > > > > > The change that Zachary is making is removing their usage, so after his > > > change they would not do anything. If he ends up committing this change, > > > these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER and > > > LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go. > > > > > > The flags are still needed for (and used by) the dotest suite, I didn't > > change that part. Normally you run that suite by doing `ninja check-lldb`, > > in which case it never goes through these lit files to begin with. But > > they will also run as part of `ninja check-lldb-lit`, but that lit > > configuration file totally overrides everything in the parent one, so > > nothing in this patch should have any effect on that. > > > I think this is actually confusing - there are two ways to specify compilers > for the lldb test suite at cmake time: > > 1. Via LLDB_TEST_USE_CUSTOM_C_COMPILER and friends > 2. Via LLDB_TEST_USER_ARGS > > As far as I can tell, the ubuntu 14 bot that @aprantl pointed to uses the > LLDB_TEST_USER_ARGS path. I *think* the green dragon bots also use the > LLDB_TEST_USER_ARGS and AFAIK it's the only way gcc is ever specified for the > tests. If the LLDB_TEST_USE_CUSTOM_C_COMPILER and friends are not used for > the lit tests, I don't think we need them for the suite tests. You're right that it's confusing, but I don't have any good ideas here. Some ideas (which are not necessarily good): - We could change the names of `LLDB_TEST_C_COMPILER` and `LLDB_TEST_CXX_COMPILER` to `LLDB_DOTEST_C_COMPILER` and `LLDB_DOTEST_CXX_COMPILER`. - We could restructure the directories under `lldb/lit` so that it looks like this: lldb \- lit |- tests |- unittests \- dotest - We could get rid of the lit folder entirely, and put everythign in the tests folder, like this: lldb \- test |- lit |- unittests \- dotest Maybe some combinatino of these (or other ideas that others have) can make things clearer. But I don't want to change too much all at once. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment.
In https://reviews.llvm.org/D54567#1300064, @zturner wrote:
> In https://reviews.llvm.org/D54567#1300029, @stella.stamenova wrote:
>
> > In https://reviews.llvm.org/D54567#129, @zturner wrote:
> >
> > > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote:
> > >
> > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote:
> > > >
> > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote:
> > > > >
> > > > > > We should also remove LLDB_TEST_C_COMPILER and
> > > > > > LLDB_TEST_CXX_COMPILER from the cmake files along with this change,
> > > > > > otherwise, people will still expect them to work.
> > > > >
> > > > >
> > > > > That would not be a good idea. There are several bots that are using
> > > > > these flags.
> > > >
> > > >
> > > > The change that Zachary is making is removing their usage, so after his
> > > > change they would not do anything. If he ends up committing this
> > > > change, these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER
> > > > and LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go.
> > >
> > >
> > > The flags are still needed for (and used by) the dotest suite, I didn't
> > > change that part. Normally you run that suite by doing `ninja
> > > check-lldb`, in which case it never goes through these lit files to begin
> > > with. But they will also run as part of `ninja check-lldb-lit`, but that
> > > lit configuration file totally overrides everything in the parent one, so
> > > nothing in this patch should have any effect on that.
> >
> >
> > I think this is actually confusing - there are two ways to specify
> > compilers for the lldb test suite at cmake time:
> >
> > 1. Via LLDB_TEST_USE_CUSTOM_C_COMPILER and friends
> > 2. Via LLDB_TEST_USER_ARGS
> >
> > As far as I can tell, the ubuntu 14 bot that @aprantl pointed to uses the
> > LLDB_TEST_USER_ARGS path. I *think* the green dragon bots also use the
> > LLDB_TEST_USER_ARGS and AFAIK it's the only way gcc is ever specified for
> > the tests. If the LLDB_TEST_USE_CUSTOM_C_COMPILER and friends are not used
> > for the lit tests, I don't think we need them for the suite tests.
>
>
> You're right that it's confusing, but I don't have any good ideas here. Some
> ideas (which are not necessarily good):
>
> - We could change the names of `LLDB_TEST_C_COMPILER` and
> `LLDB_TEST_CXX_COMPILER` to `LLDB_DOTEST_C_COMPILER` and
> `LLDB_DOTEST_CXX_COMPILER`.
> - We could restructure the directories under `lldb/lit` so that it looks like
> this:
>
> ``` lldb \- lit |- tests |- unittests \- dotest ```
> - We could get rid of the lit folder entirely, and put everythign in the
> tests folder, like this: ``` lldb \- test |- lit |- unittests \- dotest ```
>
> Maybe some combinatino of these (or other ideas that others have) can make
> things clearer. But I don't want to change too much all at once.
I actually think we should remove it entirely and rely on LLDB_USER_TEST_ARGS
because it allows for the user to specify exactly which compiler to use for the
lldb suite and it only gives the user one way to do it (instead of two which
magically get merged for the lldb suite).
In the cmake for the tests, this is what we do:
list(APPEND LLDB_TEST_COMMON_ARGS
--executable ${LLDB_TEST_EXECUTABLE}
--dsymutil ${LLDB_TEST_DSYMUTIL}
--filecheck ${LLDB_TEST_FILECHECK}
-C ${LLDB_TEST_C_COMPILER}
)
so setting the LLDB_TEST_C_COMPILER is the equivalent of passing ```-c
\path\to\compiler``` as part of the LLDB_TEST_USER_ARGS. Also, we don't
actually use the LLDB_TEST_CXX_COMPILER for the lldb suite at all.
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment.
In https://reviews.llvm.org/D54567#1300083, @stella.stamenova wrote:
> In https://reviews.llvm.org/D54567#1300064, @zturner wrote:
>
> > In https://reviews.llvm.org/D54567#1300029, @stella.stamenova wrote:
> >
> > > In https://reviews.llvm.org/D54567#129, @zturner wrote:
> > >
> > > > In https://reviews.llvm.org/D54567#123, @stella.stamenova wrote:
> > > >
> > > > > In https://reviews.llvm.org/D54567#122, @aprantl wrote:
> > > > >
> > > > > > In https://reviews.llvm.org/D54567#1299989, @stella.stamenova wrote:
> > > > > >
> > > > > > > We should also remove LLDB_TEST_C_COMPILER and
> > > > > > > LLDB_TEST_CXX_COMPILER from the cmake files along with this
> > > > > > > change, otherwise, people will still expect them to work.
> > > > > >
> > > > > >
> > > > > > That would not be a good idea. There are several bots that are
> > > > > > using these flags.
> > > > >
> > > > >
> > > > > The change that Zachary is making is removing their usage, so after
> > > > > his change they would not do anything. If he ends up committing this
> > > > > change, these two properties (along with LLDB_DEFAULT_TEST_C_COMPILER
> > > > > and LLDB_TEST_USE_CUSTOM_C_COMPILER, etc.) should also go.
> > > >
> > > >
> > > > The flags are still needed for (and used by) the dotest suite, I didn't
> > > > change that part. Normally you run that suite by doing `ninja
> > > > check-lldb`, in which case it never goes through these lit files to
> > > > begin with. But they will also run as part of `ninja check-lldb-lit`,
> > > > but that lit configuration file totally overrides everything in the
> > > > parent one, so nothing in this patch should have any effect on that.
> > >
> > >
> > > I think this is actually confusing - there are two ways to specify
> > > compilers for the lldb test suite at cmake time:
> > >
> > > 1. Via LLDB_TEST_USE_CUSTOM_C_COMPILER and friends
> > > 2. Via LLDB_TEST_USER_ARGS
> > >
> > > As far as I can tell, the ubuntu 14 bot that @aprantl pointed to uses
> > > the LLDB_TEST_USER_ARGS path. I *think* the green dragon bots also use
> > > the LLDB_TEST_USER_ARGS and AFAIK it's the only way gcc is ever specified
> > > for the tests. If the LLDB_TEST_USE_CUSTOM_C_COMPILER and friends are not
> > > used for the lit tests, I don't think we need them for the suite tests.
> >
> >
> > You're right that it's confusing, but I don't have any good ideas here.
> > Some ideas (which are not necessarily good):
> >
> > - We could change the names of `LLDB_TEST_C_COMPILER` and
> > `LLDB_TEST_CXX_COMPILER` to `LLDB_DOTEST_C_COMPILER` and
> > `LLDB_DOTEST_CXX_COMPILER`.
> > - We could restructure the directories under `lldb/lit` so that it looks
> > like this:
> >
> > ``` lldb \- lit |- tests |- unittests \- dotest ```
> > - We could get rid of the lit folder entirely, and put everythign in the
> > tests folder, like this: ``` lldb \- test |- lit |- unittests \- dotest ```
> >
> > Maybe some combinatino of these (or other ideas that others have) can
> > make things clearer. But I don't want to change too much all at once.
>
>
> I actually think we should remove it entirely and rely on LLDB_USER_TEST_ARGS
> because it allows for the user to specify exactly which compiler to use for
> the lldb suite and it only gives the user one way to do it (instead of two
> which magically get merged for the lldb suite).
>
> In the cmake for the tests, this is what we do:
>
> list(APPEND LLDB_TEST_COMMON_ARGS
> --executable ${LLDB_TEST_EXECUTABLE}
> --dsymutil ${LLDB_TEST_DSYMUTIL}
> --filecheck ${LLDB_TEST_FILECHECK}
> -C ${LLDB_TEST_C_COMPILER}
> )
>
>
> so setting the LLDB_TEST_C_COMPILER is the equivalent of passing ```-c
> \path\to\compiler``` as part of the LLDB_TEST_USER_ARGS. Also, we don't
> actually use the LLDB_TEST_CXX_COMPILER for the lldb suite at all.
That could work. Part of the existing confusion and complexity comes from the
fact that CMake is static up-front configuration but dotest has a lot of args
that control the way things run, including multiple compilers and
architectures. Trying to expose these through independent CMake variables and
building up a command line probably introduces more complexity than it
alleviates.
That said, in the interest of not changing too much all at once, it still seems
like something that's perhaps better done in a future patch. WDYT?
https://reviews.llvm.org/D54567
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
JDevlieghere added a comment. Personally I don't think we should differentiate between the lit and dotest suite when it comes to using a custom compiler. The separation between the two suits is mostly the result of what framework is easier to write your test is (or which one you're more familiar with). How hard would it be to have one variable that works for both? https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54476: [CMake] Streamline code signing for debugserver
sgraenitz updated this revision to Diff 174253.
sgraenitz marked an inline comment as not done.
sgraenitz edited the summary of this revision.
sgraenitz added a comment.
Handle reconfigurations correctly; fix configuration messages; add note for
generator expressions
https://reviews.llvm.org/D54476
Files:
test/CMakeLists.txt
tools/debugserver/CMakeLists.txt
tools/debugserver/source/CMakeLists.txt
unittests/tools/CMakeLists.txt
Index: unittests/tools/CMakeLists.txt
===
--- unittests/tools/CMakeLists.txt
+++ unittests/tools/CMakeLists.txt
@@ -1,5 +1,5 @@
if(CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|Linux|NetBSD")
- if ((CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_DEBUGSERVER) OR (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_LLDB_SERVER_BUILD))
+ if ((CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_TEST_DEBUGSERVER) OR (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_LLDB_SERVER_BUILD))
# These tests are meant to test lldb-server/debugserver in isolation, and
# don't provide any value if run against a server copied from somewhere.
else()
Index: tools/debugserver/source/CMakeLists.txt
===
--- tools/debugserver/source/CMakeLists.txt
+++ tools/debugserver/source/CMakeLists.txt
@@ -94,32 +94,102 @@
add_library(lldbDebugserverCommon ${lldbDebugserverCommonSources})
+option(LLDB_NO_DEBUGSERVER "Delete debugserver after building it, and don't try to codesign it" OFF)
+option(LLDB_USE_SYSTEM_DEBUGSERVER "Neither build nor codesign debugserver. Use the system's debugserver instead (Darwin only)." OFF)
-set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
- CACHE STRING "Identity used for code signing. Set to empty string to skip the signing step.")
+# Incompatible options
+if(LLDB_NO_DEBUGSERVER AND LLDB_USE_SYSTEM_DEBUGSERVER)
+ message(FATAL_ERROR "Inconsistent options: LLDB_NO_DEBUGSERVER and LLDB_USE_SYSTEM_DEBUGSERVER")
+endif()
-if(NOT LLDB_CODESIGN_IDENTITY STREQUAL "")
- set(DEBUGSERVER_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/debugserver${CMAKE_EXECUTABLE_SUFFIX} CACHE PATH "Path to debugserver.")
- set(SKIP_DEBUGSERVER OFF CACHE BOOL "Skip building the in-tree debug server")
-else()
+# Try to locate the system debugserver.
+# Subsequent feasibility checks depend on it.
+if(APPLE AND CMAKE_HOST_APPLE)
execute_process(
COMMAND xcode-select -p
-OUTPUT_VARIABLE XCODE_DEV_DIR)
- string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
- if(EXISTS "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/")
-set(DEBUGSERVER_PATH
- "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver" CACHE PATH "Path to debugserver.")
- elseif(EXISTS "${XCODE_DEV_DIR}/Library/PrivateFrameworks/LLDB.framework/")
-set(DEBUGSERVER_PATH
- "${XCODE_DEV_DIR}/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver" CACHE PATH "Path to debugserver.")
+OUTPUT_VARIABLE xcode_dev_dir)
+ string(STRIP ${xcode_dev_dir} xcode_dev_dir)
+
+ set(debugserver_rel_path "LLDB.framework/Resources/debugserver")
+ set(debugserver_shared "${xcode_dev_dir}/../SharedFrameworks/${debugserver_rel_path}")
+ set(debugserver_private "${xcode_dev_dir}/Library/PrivateFrameworks/${debugserver_rel_path}")
+
+ if(EXISTS ${debugserver_shared})
+set(system_debugserver ${debugserver_shared})
+ elseif(EXISTS ${debugserver_private})
+set(system_debugserver ${debugserver_private})
+ endif()
+endif()
+
+# Handle unavailability
+if(LLDB_USE_SYSTEM_DEBUGSERVER)
+ if(system_debugserver)
+set(use_system_debugserver ON)
+ elseif(APPLE AND CMAKE_HOST_APPLE)
+# Binary not found on system. Keep cached variable, to try again on reconfigure.
+message(SEND_ERROR
+ "LLDB_USE_SYSTEM_DEBUGSERVER option set, but no debugserver found in:\
+${debugserver_shared}\
+${debugserver_private}")
else()
-message(SEND_ERROR "Cannot find debugserver on system.")
+# Non-Apple target platform or non-Darwin host. Reset invalid cached variable.
+message(WARNING "Reverting invalid option LLDB_USE_SYSTEM_DEBUGSERVER (Darwin only)")
+set(LLDB_USE_SYSTEM_DEBUGSERVER OFF CACHE BOOL "" FORCE)
endif()
- set(SKIP_DEBUGSERVER ON CACHE BOOL "Skip building the in-tree debug server")
+elseif(NOT LLDB_NO_DEBUGSERVER)
+ # Default case: on Darwin we need the right code signing ID.
+ # See lldb/docs/code-signing.txt for details.
+ if(CMAKE_HOST_APPLE AND NOT LLVM_CODESIGNING_IDENTITY STREQUAL "lldb_codesign")
+set(msg "Cannot code sign debugserver with identity '${LLVM_CODESIGNING_IDENTITY}'.")
+if(system_debugserver)
+ message(WARNING "${msg} Will fall back to system's debugserver.")
+ set(use_system_debugserver ON)
+else()
+ message(WARNING "${msg} debugserver will not be available.")
+endif()
+ else()
+set(build_and_sign_debugserver ON)
+ endif()
+endif()
+
+# TODO: We don't use the $ generator expression he
[Lldb-commits] [lldb] r346981 - Port the Darwin universal binary testcase to x86_64.
Author: adrian
Date: Thu Nov 15 11:15:03 2018
New Revision: 346981
URL: http://llvm.org/viewvc/llvm-project?rev=346981&view=rev
Log:
Port the Darwin universal binary testcase to x86_64.
Xcode 10 doesn't ship with an i386 SDK any more. This patch ports the
testcase from an i386/x86_64 -> x86_64/x86_64h universal binary.
rdar://problem/46099343
Modified:
lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/Makefile
lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/TestUniversal.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/Makefile?rev=346981&r1=346980&r2=346981&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/Makefile
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/Makefile Thu Nov
15 11:15:03 2018
@@ -1,21 +1,25 @@
-CC ?= clang
+LEVEL := ../../make
+
+EXE := testit
+
+include $(LEVEL)/Makefile.rules
all: testit
-testit: testit.i386 testit.x86_64
+testit: testit.x86_64h testit.x86_64
lipo -create -o testit $^
-testit.i386: testit.i386.o
- $(CC) -arch i386 -o testit.i386 $<
+testit.x86_64h: testit.x86_64h.o
+ $(CC) -arch x86_64h -o testit.x86_64h $<
testit.x86_64: testit.x86_64.o
$(CC) -arch x86_64 -o testit.x86_64 $<
-testit.i386.o: main.c
- $(CC) -g -O0 -arch i386 -c -o testit.i386.o $<
+testit.x86_64h.o: main.c
+ $(CC) -g -O0 -arch x86_64h -c -o testit.x86_64h.o $<
testit.x86_64.o: main.c
$(CC) -g -O0 -arch x86_64 -c -o testit.x86_64.o $<
-clean:
+clean::
rm -rf $(wildcard testit* *~)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/TestUniversal.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/TestUniversal.py?rev=346981&r1=346980&r2=346981&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/TestUniversal.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/macosx/universal/TestUniversal.py
Thu Nov 15 11:15:03 2018
@@ -11,9 +11,13 @@ from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
+def haswellOrLater():
+features = subprocess.check_output(["sysctl", "machdep.cpu"])
+return "AVX2" in features.split()
class UniversalTestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
mydir = TestBase.compute_mydir(__file__)
def setUp(self):
@@ -24,8 +28,8 @@ class UniversalTestCase(TestBase):
@add_test_categories(['pyapi'])
@skipUnlessDarwin
-@unittest2.skipUnless(hasattr(os, "uname") and os.uname()[4] in [
- 'i386', 'x86_64'], "requires i386 or x86_64")
+@unittest2.skipUnless(hasattr(os, "uname") and os.uname()[4] in
+ ['x86_64'], "requires x86_64")
@skipIfDarwinEmbedded # this test file assumes we're targetting an x86
system
def test_sbdebugger_create_target_with_file_and_target_triple(self):
"""Test the SBDebugger.CreateTargetWithFileAndTargetTriple() API."""
@@ -37,8 +41,9 @@ class UniversalTestCase(TestBase):
# Create a target by the debugger.
target = self.dbg.CreateTargetWithFileAndTargetTriple(
-exe, "i386-apple-macosx")
+exe, "x86_64-apple-macosx")
self.assertTrue(target, VALID_TARGET)
+self.expect("image list -A -b", substrs=["x86_64 testit"])
# Now launch the process, and do not stop at entry point.
process = target.LaunchSimple(
@@ -46,13 +51,16 @@ class UniversalTestCase(TestBase):
self.assertTrue(process, PROCESS_IS_VALID)
@skipUnlessDarwin
-@unittest2.skipUnless(hasattr(os, "uname") and os.uname()[4] in [
- 'i386', 'x86_64'], "requires i386 or x86_64")
+@unittest2.skipUnless(hasattr(os, "uname") and os.uname()[4] in
+ ['x86_64'], "requires x86_64")
@skipIfDarwinEmbedded # this test file assumes we're targetting an x86
system
def test_process_launch_for_universal(self):
"""Test process launch of a universal binary."""
from lldbsuite.test.lldbutil import print_registers
+if not haswellOrLater():
+return
+
# Invoke the default build rule.
self.build()
@@ -62,69 +70,54 @@ class UniversalTestCase(TestBase):
# By default, x86_64 is assumed if no architecture is specified.
self.expect("file " + exe, CURRENT_EXECUTABLE_SET,
startstr="Current executable set to ",
-substrs=["testit' (x86_64)."])
+substrs=["testit' (x86_64h)."])
# Break inside the main.
lldbutil.ru
[Lldb-commits] [PATCH] D54476: [CMake] Streamline code signing for debugserver
sgraenitz updated this revision to Diff 174254.
sgraenitz added a comment.
Improve description for options LLDB_NO_DEBUGSERVER and
LLDB_USE_SYSTEM_DEBUGSERVER
https://reviews.llvm.org/D54476
Files:
test/CMakeLists.txt
tools/debugserver/CMakeLists.txt
tools/debugserver/source/CMakeLists.txt
unittests/tools/CMakeLists.txt
Index: unittests/tools/CMakeLists.txt
===
--- unittests/tools/CMakeLists.txt
+++ unittests/tools/CMakeLists.txt
@@ -1,5 +1,5 @@
if(CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|Linux|NetBSD")
- if ((CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_DEBUGSERVER) OR (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_LLDB_SERVER_BUILD))
+ if ((CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_TEST_DEBUGSERVER) OR (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" AND SKIP_LLDB_SERVER_BUILD))
# These tests are meant to test lldb-server/debugserver in isolation, and
# don't provide any value if run against a server copied from somewhere.
else()
Index: tools/debugserver/source/CMakeLists.txt
===
--- tools/debugserver/source/CMakeLists.txt
+++ tools/debugserver/source/CMakeLists.txt
@@ -94,32 +94,102 @@
add_library(lldbDebugserverCommon ${lldbDebugserverCommonSources})
+option(LLDB_NO_DEBUGSERVER "Disable the debugserver target" OFF)
+option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's debugserver instead of building it from source (Darwin only)." OFF)
-set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
- CACHE STRING "Identity used for code signing. Set to empty string to skip the signing step.")
+# Incompatible options
+if(LLDB_NO_DEBUGSERVER AND LLDB_USE_SYSTEM_DEBUGSERVER)
+ message(FATAL_ERROR "Inconsistent options: LLDB_NO_DEBUGSERVER and LLDB_USE_SYSTEM_DEBUGSERVER")
+endif()
-if(NOT LLDB_CODESIGN_IDENTITY STREQUAL "")
- set(DEBUGSERVER_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/debugserver${CMAKE_EXECUTABLE_SUFFIX} CACHE PATH "Path to debugserver.")
- set(SKIP_DEBUGSERVER OFF CACHE BOOL "Skip building the in-tree debug server")
-else()
+# Try to locate the system debugserver.
+# Subsequent feasibility checks depend on it.
+if(APPLE AND CMAKE_HOST_APPLE)
execute_process(
COMMAND xcode-select -p
-OUTPUT_VARIABLE XCODE_DEV_DIR)
- string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
- if(EXISTS "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/")
-set(DEBUGSERVER_PATH
- "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver" CACHE PATH "Path to debugserver.")
- elseif(EXISTS "${XCODE_DEV_DIR}/Library/PrivateFrameworks/LLDB.framework/")
-set(DEBUGSERVER_PATH
- "${XCODE_DEV_DIR}/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver" CACHE PATH "Path to debugserver.")
+OUTPUT_VARIABLE xcode_dev_dir)
+ string(STRIP ${xcode_dev_dir} xcode_dev_dir)
+
+ set(debugserver_rel_path "LLDB.framework/Resources/debugserver")
+ set(debugserver_shared "${xcode_dev_dir}/../SharedFrameworks/${debugserver_rel_path}")
+ set(debugserver_private "${xcode_dev_dir}/Library/PrivateFrameworks/${debugserver_rel_path}")
+
+ if(EXISTS ${debugserver_shared})
+set(system_debugserver ${debugserver_shared})
+ elseif(EXISTS ${debugserver_private})
+set(system_debugserver ${debugserver_private})
+ endif()
+endif()
+
+# Handle unavailability
+if(LLDB_USE_SYSTEM_DEBUGSERVER)
+ if(system_debugserver)
+set(use_system_debugserver ON)
+ elseif(APPLE AND CMAKE_HOST_APPLE)
+# Binary not found on system. Keep cached variable, to try again on reconfigure.
+message(SEND_ERROR
+ "LLDB_USE_SYSTEM_DEBUGSERVER option set, but no debugserver found in:\
+${debugserver_shared}\
+${debugserver_private}")
else()
-message(SEND_ERROR "Cannot find debugserver on system.")
+# Non-Apple target platform or non-Darwin host. Reset invalid cached variable.
+message(WARNING "Reverting invalid option LLDB_USE_SYSTEM_DEBUGSERVER (Darwin only)")
+set(LLDB_USE_SYSTEM_DEBUGSERVER OFF CACHE BOOL "" FORCE)
endif()
- set(SKIP_DEBUGSERVER ON CACHE BOOL "Skip building the in-tree debug server")
+elseif(NOT LLDB_NO_DEBUGSERVER)
+ # Default case: on Darwin we need the right code signing ID.
+ # See lldb/docs/code-signing.txt for details.
+ if(CMAKE_HOST_APPLE AND NOT LLVM_CODESIGNING_IDENTITY STREQUAL "lldb_codesign")
+set(msg "Cannot code sign debugserver with identity '${LLVM_CODESIGNING_IDENTITY}'.")
+if(system_debugserver)
+ message(WARNING "${msg} Will fall back to system's debugserver.")
+ set(use_system_debugserver ON)
+else()
+ message(WARNING "${msg} debugserver will not be available.")
+endif()
+ else()
+set(build_and_sign_debugserver ON)
+ endif()
+endif()
+
+# TODO: We don't use the $ generator expression here,
+# because the value of DEBUGSERVER_PATH is used to build LLDB_DOTEST_ARGS,
+# which is used for configuring lldb-dotest.in, which does not have a generat
[Lldb-commits] [PATCH] D54476: [CMake] Streamline code signing for debugserver
sgraenitz added a comment.
Last revision changed a lot, but I think support for reconfigurations is worth
it.
The current state would be acceptable from my side now -- if I didn't miss
anything! :-)
Comment at: tools/debugserver/source/CMakeLists.txt:101
+option(LLDB_NO_DEBUGSERVER "Delete debugserver after building it, and don't
try to codesign it" OFF)
+option(LLDB_USE_SYSTEM_DEBUGSERVER "Neither build nor codesign debugserver.
Use the system's debugserver instead (Darwin only)." OFF)
+
labath wrote:
> sgraenitz wrote:
> > JDevlieghere wrote:
> > > Should we emit and error if these variables are in an inconsistent state,
> > > e.g. when both are set?
> > Yes, could do that.
> Alternatively, we could make this a single tri-state variable.
> `LLDB_DEBUGSERVER_MODE=OFF|SYSTEM|TREE` or something ?
Yes possible, but I hope it's not necessary. It would be great to keep existing
names for user-definable options where possible. Otherwise it breaks bots, etc.
Comment at: tools/debugserver/source/CMakeLists.txt:159
+# step at the moment.
+set(default_debugserver_path
"${LLVM_TOOLS_BINARY_DIR}/debugserver${CMAKE_EXECUTABLE_SUFFIX}")
+
This is not a regression. Just added a verbose comment to remember once we look
at this.
Comment at: tools/debugserver/source/CMakeLists.txt:190
+ message(STATUS "lldb debugserver will not be available.")
endif()
This is resetting `DEBUGSERVER_PATH` and `SKIP_TEST_DEBUGSERVER` cached
variables for the 3 non-error cases (see updated summary). It should be
reconfiguration-safe. All manual testing on Darwin passed.
https://reviews.llvm.org/D54476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D53008: Add a check whether or not a str is utf8 prior to emplacing
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB346988: Add a check whether or not a str is utf8 prior to
emplacing (authored by lanza, committed by ).
Herald added subscribers: lldb-commits, abidh.
Changed prior to commit:
https://reviews.llvm.org/D53008?vs=174134&id=174264#toc
Repository:
rLLDB LLDB
https://reviews.llvm.org/D53008
Files:
tools/lldb-vscode/JSONUtils.cpp
tools/lldb-vscode/JSONUtils.h
tools/lldb-vscode/VSCode.cpp
tools/lldb-vscode/lldb-vscode.cpp
Index: tools/lldb-vscode/JSONUtils.h
===
--- tools/lldb-vscode/JSONUtils.h
+++ tools/lldb-vscode/JSONUtils.h
@@ -16,7 +16,24 @@
#include "VSCodeForward.h"
namespace lldb_vscode {
-
+
+//--
+/// Emplace a StringRef in a json::Object after enusring that the
+/// string is valid UTF8. If not, first call llvm::json::fixUTF8
+/// before emplacing.
+///
+/// @param[in] obj
+/// A JSON object that we will attempt to emplace the value in
+///
+/// @param[in] key
+/// The key to use when emplacing the value
+///
+/// @param[in] str
+/// The string to emplace
+//--
+void EmplaceSafeString(llvm::json::Object &obj, llvm::StringRef key,
+ llvm::StringRef str);
+
//--
/// Extract simple values as a string.
///
Index: tools/lldb-vscode/lldb-vscode.cpp
===
--- tools/lldb-vscode/lldb-vscode.cpp
+++ tools/lldb-vscode/lldb-vscode.cpp
@@ -289,7 +289,7 @@
exe_fspec.GetPath(exe_path, sizeof(exe_path));
llvm::json::Object event(CreateEventObject("process"));
llvm::json::Object body;
- body.try_emplace("name", std::string(exe_path));
+ EmplaceSafeString(body, "name", std::string(exe_path));
const auto pid = g_vsc.target.GetProcess().GetProcessID();
body.try_emplace("systemProcessId", (int64_t)pid);
body.try_emplace("isLocalProcess", true);
@@ -539,7 +539,7 @@
g_vsc.target.AddModule(program.data(), target_triple, uuid_cstr, symfile);
if (error.Fail()) {
response.try_emplace("success", false);
- response.try_emplace("message", std::string(error.GetCString()));
+ EmplaceSafeString(response, "message", std::string(error.GetCString()));
g_vsc.SendJSON(llvm::json::Value(std::move(response)));
return;
}
@@ -591,7 +591,7 @@
if (error.Fail()) {
response.try_emplace("success", false);
-response.try_emplace("message", std::string(error.GetCString()));
+EmplaceSafeString(response, "message", std::string(error.GetCString()));
}
g_vsc.SendJSON(llvm::json::Value(std::move(response)));
if (error.Success()) {
@@ -813,8 +813,8 @@
else if (stopReason == lldb::eStopReasonBreakpoint) {
ExceptionBreakpoint *exc_bp = g_vsc.GetExceptionBPFromStopReason(thread);
if (exc_bp) {
-body.try_emplace("exceptionId", exc_bp->filter);
-body.try_emplace("description", exc_bp->label);
+EmplaceSafeString(body, "exceptionId", exc_bp->filter);
+EmplaceSafeString(body, "description", exc_bp->label);
} else {
body.try_emplace("exceptionId", "exception");
}
@@ -824,7 +824,7 @@
if (!ObjectContainsKey(body, "description")) {
char description[1024];
if (thread.GetStopDescription(description, sizeof(description))) {
-body.try_emplace("description", std::string(description));
+EmplaceSafeString(body, "description", std::string(description));
}
}
body.try_emplace("breakMode", "always");
@@ -951,9 +951,9 @@
const auto expression = GetString(arguments, "expression");
if (!expression.empty() && expression[0] == '`') {
-body.try_emplace("result",
- RunLLDBCommands(llvm::StringRef(),
- {expression.substr(1)}));
+auto result = RunLLDBCommands(llvm::StringRef(),
+ {expression.substr(1)});
+EmplaceSafeString(body, "result", result);
body.try_emplace("variablesReference", (int64_t)0);
} else {
// Always try to get the answer from the local variables if possible. If
@@ -968,13 +968,13 @@
response.try_emplace("success", false);
const char *error_cstr = value.GetError().GetCString();
if (error_cstr && error_cstr[0])
-response.try_emplace("message", std::string(error_cstr));
+EmplaceSafeString(response, "message", std::string(error_cstr));
else
-response.try_emplace("message", "evaluate failed");
+EmplaceSafeString(response, "message", "evaluate failed");
} else {
SetValueForKey(value, body, "result");
auto value_typename = value.GetType().GetDisplayTypeName();
- body.try_emplace("type", valu
[Lldb-commits] [lldb] r346991 - A unit test file moved.
Author: jmolenda
Date: Thu Nov 15 12:28:55 2018
New Revision: 346991
URL: http://llvm.org/viewvc/llvm-project?rev=346991&view=rev
Log:
A unit test file moved.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=346991&r1=346990&r2=346991&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Nov 15 12:28:55 2018
@@ -254,7 +254,7 @@
49CA96FD1E6AACC900C03FEE /* DataBufferLLVM.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 49CA96E71E6AAC6600C03FEE /* DataBufferLLVM.cpp
*/; };
49CA96FE1E6AACC900C03FEE /* DataEncoder.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 49CA96E81E6AAC6600C03FEE /* DataEncoder.cpp */;
};
49CA96FF1E6AACC900C03FEE /* DataExtractor.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 49CA96E91E6AAC6600C03FEE /* DataExtractor.cpp
*/; };
- 23CB15391D66DA9300EDDDE1 /* DataExtractorTest.cpp in Sources */
= {isa = PBXBuildFile; fileRef = 23CB14E81D66CC0E00EDDDE1 /*
DataExtractorTest.cpp */; };
+ AFA1B62C219E0ED900A8AB7E /* DataExtractorTest.cpp in Sources */
= {isa = PBXBuildFile; fileRef = AFA1B62B219E0ED900A8AB7E /*
DataExtractorTest.cpp */; };
94CB255C16B069770059775D /* DataVisualization.cpp in Sources */
= {isa = PBXBuildFile; fileRef = 94CB255816B069770059775D /*
DataVisualization.cpp */; };
23D4007E1C210201000C3885 /* DebugMacros.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 23E77CDB1C20F2F2007192AD /* DebugMacros.cpp */;
};
AF116BEF20CF234B0071093F /* DebugNamesDWARFIndex.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = AF116BED20CF234B0071093F /*
DebugNamesDWARFIndex.cpp */; };
@@ -1745,7 +1745,7 @@
49CA96F31E6AAC8E00C03FEE /* DataEncoder.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name =
DataEncoder.h; path = include/lldb/Utility/DataEncoder.h; sourceTree =
""; };
49CA96E91E6AAC6600C03FEE /* DataExtractor.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = DataExtractor.cpp; path = source/Utility/DataExtractor.cpp; sourceTree =
""; };
49CA96F41E6AAC8E00C03FEE /* DataExtractor.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name =
DataExtractor.h; path = include/lldb/Utility/DataExtractor.h; sourceTree =
""; };
- 23CB14E81D66CC0E00EDDDE1 /* DataExtractorTest.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = DataExtractorTest.cpp; sourceTree = ""; };
+ AFA1B62B219E0ED900A8AB7E /* DataExtractorTest.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = DataExtractorTest.cpp; sourceTree = ""; };
94CB255816B069770059775D /* DataVisualization.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
name = DataVisualization.cpp; path =
source/DataFormatters/DataVisualization.cpp; sourceTree = ""; };
94CB256016B069800059775D /* DataVisualization.h */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.h; name =
DataVisualization.h; path = include/lldb/DataFormatters/DataVisualization.h;
sourceTree = ""; };
3FDFED1E19BA6D55009756A7 /* Debug.h */ = {isa =
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = Debug.h; path =
include/lldb/Host/Debug.h; sourceTree = ""; };
@@ -3558,6 +3558,7 @@
7F94D7172040A13A006EE3EA /* CleanUpTest.cpp */,
23E2E5161D903689006F38BB /* ArchSpecTest.cpp */,
9A3D43C81F3150D200EB767C /* ConstStringTest.cpp
*/,
+ AFA1B62B219E0ED900A8AB7E /*
DataExtractorTest.cpp */,
23CB14FD1D66CD2400EDDDE1 /* FileSpecTest.cpp */,
8C3BD99F1EF5D1B50016C343 /* JSONTest.cpp */,
9A3D43C71F3150D200EB767C /* LogTest.cpp */,
@@ -3721,7 +3722,6 @@
children = (
23CB14E61D66CC0E00EDDDE1 /* BroadcasterTest.cpp
*/,
23CB14E71D66CC0E00EDDDE1 /* CMakeLists.txt */,
- 23CB14E81D66CC0E00EDDDE1 /*
DataExtractorTest.cpp */,
58A080B12112AB2200D5580F /* HighlighterTest.cpp
*/,
9A3D43E31F3237D500EB767C /* ListenerTest.cpp */,
4F29D3CD21010F84003B549A /* MangledTest.cpp */,
@@ -7544,6 +7544,7 @@
58A080B3
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
stella.stamenova added a comment. > That said, in the interest of not changing too much all at once, it still > seems like something that's perhaps better done in a future patch. WDYT? I actually think it would be better now - the people who use the properties for compile the lit tests will have to make a change now anyway and those are most likely the same people that use the properties to compile the lldb suite tests, so they could make a change once and have both working rather than making it a two-step process. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54510: Force SHELL to be cmd.exe on Windows for the test suite
This revision was automatically updated to reflect the committed changes. Closed by commit rLLDB346993: Force SHELL to be cmd.exe on Windows for the test suite (authored by lanza, committed by ). Herald added a subscriber: lldb-commits. Changed prior to commit: https://reviews.llvm.org/D54510?vs=173984&id=174271#toc Repository: rLLDB LLDB https://reviews.llvm.org/D54510 Files: packages/Python/lldbsuite/test/make/Makefile.rules Index: packages/Python/lldbsuite/test/make/Makefile.rules === --- packages/Python/lldbsuite/test/make/Makefile.rules +++ packages/Python/lldbsuite/test/make/Makefile.rules @@ -51,6 +51,17 @@ endif #-- +# If OS is Windows, force SHELL to be cmd +# +# Some versions of make on Windows will search for other shells such as +# C:\cygwin\bin\sh.exe. This shell fails for numerous different reasons +# so default to using cmd.exe. +#-- +ifeq "$(OS)" "Windows_NT" + SHELL = $(WINDIR)\system32\cmd.exe +endif + +#-- # If TRIPLE is not defined try to set the ARCH, CC, CFLAGS, and more # from the triple alone #-- Index: packages/Python/lldbsuite/test/make/Makefile.rules === --- packages/Python/lldbsuite/test/make/Makefile.rules +++ packages/Python/lldbsuite/test/make/Makefile.rules @@ -51,6 +51,17 @@ endif #-- +# If OS is Windows, force SHELL to be cmd +# +# Some versions of make on Windows will search for other shells such as +# C:\cygwin\bin\sh.exe. This shell fails for numerous different reasons +# so default to using cmd.exe. +#-- +ifeq "$(OS)" "Windows_NT" + SHELL = $(WINDIR)\system32\cmd.exe +endif + +#-- # If TRIPLE is not defined try to set the ARCH, CC, CFLAGS, and more # from the triple alone #-- ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54544: Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB346994: Implement basic DidAttach and DidLaunch for
DynamicLoaderWindowsDYLD (authored by lanza, committed by ).
Herald added subscribers: lldb-commits, abidh.
Changed prior to commit:
https://reviews.llvm.org/D54544?vs=174097&id=174272#toc
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54544
Files:
packages/Python/lldbsuite/test/functionalities/windows_dyld/Makefile
packages/Python/lldbsuite/test/functionalities/windows_dyld/TestWindowsDYLD.py
packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.c
packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.mk
packages/Python/lldbsuite/test/functionalities/windows_dyld/main.c
packages/Python/lldbsuite/test/make/Makefile.rules
source/Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.cpp
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -525,7 +525,7 @@
endif
else
$(EXE) : $(OBJECTS) $(ARCHIVE_NAME)
- $(LD) $(OBJECTS) $(LDFLAGS) $(ARCHIVE_NAME) -o "$(EXE)"
+ "$(LD)" $(OBJECTS) $(LDFLAGS) $(ARCHIVE_NAME) -o "$(EXE)"
ifneq "$(CODESIGN)" ""
$(CODESIGN) -s - "$(EXE)"
endif
@@ -582,7 +582,7 @@
endif
endif
else
- $(LD) $(DYLIB_OBJECTS) $(LDFLAGS) -shared -o "$(DYLIB_FILENAME)"
+ "$(LD)" $(DYLIB_OBJECTS) $(LDFLAGS) -shared -o "$(DYLIB_FILENAME)"
ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES"
$(OBJCOPY) --only-keep-debug "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME).debug"
$(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DYLIB_FILENAME).debug" "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME)"
Index: packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.mk
===
--- packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.mk
+++ packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.mk
@@ -0,0 +1,7 @@
+LEVEL := ../../make
+
+DYLIB_NAME := dllfunc
+DYLIB_C_SOURCES := dllfunc.c
+DYLIB_ONLY := YES
+
+include $(LEVEL)/Makefile.rules
Index: packages/Python/lldbsuite/test/functionalities/windows_dyld/Makefile
===
--- packages/Python/lldbsuite/test/functionalities/windows_dyld/Makefile
+++ packages/Python/lldbsuite/test/functionalities/windows_dyld/Makefile
@@ -0,0 +1,14 @@
+LEVEL := ../../make
+
+LD_EXTRAS := -ldllfunc
+C_SOURCES := main.c
+
+include $(LEVEL)/Makefile.rules
+
+a.out: dllfunc
+
+dllfunc:
+ $(MAKE) VERBOSE=1 VPATH=$(SRCDIR) -I $(SRCDIR) -f $(SRCDIR)/dllfunc.mk
+
+clean::
+ $(MAKE) -f $(SRCDIR)/dllfunc.mk clean
Index: packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.c
===
--- packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.c
+++ packages/Python/lldbsuite/test/functionalities/windows_dyld/dllfunc.c
@@ -0,0 +1,19 @@
+//===-- a.c -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include
+
+BOOL WINAPI DllMain(HINSTANCE h, DWORD reason, void* reserved) {
+ return TRUE;
+}
+
+int __declspec(dllexport) DllFunc(int n) {
+ int x = n * n;
+ return x; // set breakpoint here
+}
Index: packages/Python/lldbsuite/test/functionalities/windows_dyld/main.c
===
--- packages/Python/lldbsuite/test/functionalities/windows_dyld/main.c
+++ packages/Python/lldbsuite/test/functionalities/windows_dyld/main.c
@@ -0,0 +1,19 @@
+//===-- main.c --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include
+
+int __declspec(dllimport) DllFunc(int n);
+
+int main(int argc, char ** argv) {
+ int x = DllFunc(4);
+ int y = DllFunc(8); // set breakpoint here
+ int z = DllFunc(16);
+ return x + y + z;
+}
Index: packages/Python/lldbsuite/test/functionalities/windows_dyld/TestWindowsDYLD.py
===
--- packages/Python/lldbsuite/test/functionalities/windows_dyld/TestWindowsDYLD.py
+++ packages/Python/lldbsuite/test/functionalities/windows_dyld/TestWindowsDYLD.py
@@ -0,0 +1,42 @@
+"""
+Test that breakpoints work in a DLL
+"""
+
+from __future__ import print_function
+
+import lldb
+from lldbsuite.test.decorators impo
[Lldb-commits] [PATCH] D54544: Implement basic DidAttach and DidLaunch for DynamicLoaderWindowsDYLD
Hui added inline comments.
Comment at:
source/Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.cpp:75
+
+void DynamicLoaderWindowsDYLD::DidLaunch() {
+ Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
I think DynamicLoaderWindowsDYLD::DidAttach & DidLaunch are intended for remote
debugging. As the similar functionalities have been done in
ProcessWindows::DidLaunch & DidAttach, the test in here is actually testing
those native ones and they happen to be correct.
Comment at:
source/Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.cpp:102
+
+ UpdateLoadedSections(executable, LLDB_INVALID_ADDRESS, base_addr, false);
A remote debugging shows if the 'qFileLoadAddress' remote packet is not
implemented or incorrectly handled, GetFileLoadAddress by the remote process
will return error resulting base_addr stay '0. Since you are calling with the
last argument 'false' to indicate it is not an offset, that will be an issue.
Better to move it to line 99 and check if the load_addr is LLDB_INVALID_ADDRESS.
Moreover, if the load_addr is changed, make sure all the breakpoint address is
recalculated. This feature could be a little bit complicated.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r346999 - Fix compilation failure in unit tests on Windows.
Author: zturner
Date: Thu Nov 15 14:03:49 2018
New Revision: 346999
URL: http://llvm.org/viewvc/llvm-project?rev=346999&view=rev
Log:
Fix compilation failure in unit tests on Windows.
Modified:
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.cpp
Modified: lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.cpp?rev=346999&r1=346998&r2=346999&view=diff
==
--- lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.cpp (original)
+++ lldb/trunk/unittests/Process/gdb-remote/GDBRemoteTestUtils.cpp Thu Nov 15
14:03:49 2018
@@ -9,6 +9,11 @@
#include "GDBRemoteTestUtils.h"
+#if defined(_MSC_VER)
+#include "lldb/Host/windows/windows.h"
+#include
+#endif
+
namespace lldb_private {
namespace process_gdb_remote {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#1300183, @JDevlieghere wrote: > Personally I don't think we should differentiate between the lit and dotest > suite when it comes to using a custom compiler. The separation between the > two suits is mostly the result of what framework is easier to write your test > is (or which one you're more familiar with). How hard would it be to have one > variable that works for both? I'm not sure how hard it would be. One problem is that dotest supports not just choosing a compiler, but choosing multiple compilers, as well as multiple architectures and it runs the test suite over the cross product of all of these. That's hard to express in CMake. This is why, for example, people end up subverting it entirely for productionizing test suite runs, such as what you see on the ubuntu bot linked earlier. It doesn't even use the CMake variables for running the dotest suite, it just has scripts that build command lines and runs them. There is another issue I'm aware of, which is that some people's compilers have version numbers embedded in the binary name. Right now the code that uses `LLDB_LIT_TOOLS_DIR` to find the binaries won't handle these cases, because it looks specifically for `clang` and `clang++`, but not, for example, `clang-7.0` or `clang++-hexagon-7.0`. I do think an iterative approach is better though. This is already a big change and as this thread (and the previous patch which is what I'm trying to fix) shows, people use things in a lot of different ways so changing something has potential for lots of breakage in subtle ways. So I still kind of prefer doing things incrementally, letting people tell me what's broken, and then working on a solution. We could try to converge on the single `LLDB_LIT_TOOLS_DIR` approach for both dotest as well as the lit suite, because having one variable with simple semantics is nice. But I think we should worry first about getting to a known good baseline and then working incrementally to make simplifications. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54601: Makefile.rules: Use a shared clang module cache directory.
aprantl created this revision.
aprantl added reviewers: JDevlieghere, davide, jingham, vsk.
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
https://reviews.llvm.org/D54601
Files:
lit/lit.cfg.py
packages/Python/lldbsuite/test/make/Makefile.rules
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -33,7 +33,6 @@
THIS_FILE_DIR := $(shell dirname $(lastword $(MAKEFILE_LIST)))/
LLDB_BASE_DIR := $(THIS_FILE_DIR)../../../../../
-
#--
# If OS is not defined, use 'uname -s' to determine the OS name.
#
@@ -242,7 +241,12 @@
CFLAGS += -gsplit-dwarf
endif
+# Use a shared module cache when building in the default test build directory.
+ifeq "$(findstring lldb-test-build.noindex, $(BUILDDIR))" ""
CLANG_MODULE_CACHE_DIR := $(BUILDDIR)/module-cache
+else
+CLANG_MODULE_CACHE_DIR := $(shell echo "$(BUILDDIR)" | sed
's/lldb-test-build.noindex.*/lldb-test-build.noindex\/module-cache-clang')
+endif
MANDATORY_MODULE_BUILD_CFLAGS := -fmodules -gmodules
-fmodules-cache-path=$(CLANG_MODULE_CACHE_DIR)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -4,9 +4,9 @@
import sys
import re
import platform
+import shutil
import subprocess
-
import lit.util
import lit.formats
from lit.llvm import llvm_config
@@ -124,3 +124,12 @@
('--build-mode', {'DEBUG': 'debug'}),
('--targets-built', calculate_arch_features)
])
+
+# Clean the module caches in the test build directory. This is
+# necessary in an incremental build whenever clang changes underneath,
+# so doing it once per lit.py invocation is close enough.
+for i in ['module-cache-clang']:
+cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
+if os.path.isdir(cachedir):
+print("Deleting module cache at %s."%cachedir)
+shutil.rmtree(cachedir)
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -33,7 +33,6 @@
THIS_FILE_DIR := $(shell dirname $(lastword $(MAKEFILE_LIST)))/
LLDB_BASE_DIR := $(THIS_FILE_DIR)../../../../../
-
#--
# If OS is not defined, use 'uname -s' to determine the OS name.
#
@@ -242,7 +241,12 @@
CFLAGS += -gsplit-dwarf
endif
+# Use a shared module cache when building in the default test build directory.
+ifeq "$(findstring lldb-test-build.noindex, $(BUILDDIR))" ""
CLANG_MODULE_CACHE_DIR := $(BUILDDIR)/module-cache
+else
+CLANG_MODULE_CACHE_DIR := $(shell echo "$(BUILDDIR)" | sed 's/lldb-test-build.noindex.*/lldb-test-build.noindex\/module-cache-clang')
+endif
MANDATORY_MODULE_BUILD_CFLAGS := -fmodules -gmodules -fmodules-cache-path=$(CLANG_MODULE_CACHE_DIR)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -4,9 +4,9 @@
import sys
import re
import platform
+import shutil
import subprocess
-
import lit.util
import lit.formats
from lit.llvm import llvm_config
@@ -124,3 +124,12 @@
('--build-mode', {'DEBUG': 'debug'}),
('--targets-built', calculate_arch_features)
])
+
+# Clean the module caches in the test build directory. This is
+# necessary in an incremental build whenever clang changes underneath,
+# so doing it once per lit.py invocation is close enough.
+for i in ['module-cache-clang']:
+cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
+if os.path.isdir(cachedir):
+print("Deleting module cache at %s."%cachedir)
+shutil.rmtree(cachedir)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54602: Use a shared module cache directory for LLDB.
aprantl created this revision.
aprantl added reviewers: JDevlieghere, davide, jingham, vsk.
aprantl added a dependency: D54601: Makefile.rules: Use a shared clang module
cache directory..
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
rdar://problem/36002081
https://reviews.llvm.org/D54602
Files:
lit/lit.cfg.py
packages/Python/lldbsuite/test/lldbtest.py
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1862,8 +1862,9 @@
# decorators.
Base.setUp(self)
-# Set the clang modules cache path.
-mod_cache = os.path.join(self.getBuildDir(), "module-cache-lldb")
+# Set the clang modules cache path used by LLDB.
+mod_cache = os.path.join(os.path.join(os.environ["LLDB_BUILD"],
+ "module-cache-lldb"))
self.runCmd('settings set symbols.clang-modules-cache-path "%s"'
% mod_cache)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -128,7 +128,7 @@
# Clean the module caches in the test build directory. This is
# necessary in an incremental build whenever clang changes underneath,
# so doing it once per lit.py invocation is close enough.
-for i in ['module-cache-clang']:
+for i in ['module-cache-clang', 'module-cache-lldb']:
cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
if os.path.isdir(cachedir):
print("Deleting module cache at %s."%cachedir)
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1862,8 +1862,9 @@
# decorators.
Base.setUp(self)
-# Set the clang modules cache path.
-mod_cache = os.path.join(self.getBuildDir(), "module-cache-lldb")
+# Set the clang modules cache path used by LLDB.
+mod_cache = os.path.join(os.path.join(os.environ["LLDB_BUILD"],
+ "module-cache-lldb"))
self.runCmd('settings set symbols.clang-modules-cache-path "%s"'
% mod_cache)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -128,7 +128,7 @@
# Clean the module caches in the test build directory. This is
# necessary in an incremental build whenever clang changes underneath,
# so doing it once per lit.py invocation is close enough.
-for i in ['module-cache-clang']:
+for i in ['module-cache-clang', 'module-cache-lldb']:
cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
if os.path.isdir(cachedir):
print("Deleting module cache at %s."%cachedir)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54601: Makefile.rules: Use a shared clang module cache directory.
JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D54601 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54602: Use a shared module cache directory for LLDB.
JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D54602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54476: [CMake] Streamline code signing for debugserver
JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land. Thanks for working on this, Stefan. This LGTM. https://reviews.llvm.org/D54476 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
JDevlieghere added a comment. In https://reviews.llvm.org/D54567#1300459, @zturner wrote: > I'm not sure how hard it would be. > > One problem is that dotest supports not just choosing a compiler, but > choosing multiple compilers, as well as multiple architectures and it runs > the test suite over the cross product of all of these. That's hard to > express in CMake. This is why, for example, people end up subverting it > entirely for productionizing test suite runs, such as what you see on the > ubuntu bot linked earlier. It doesn't even use the CMake variables for > running the dotest suite, it just has scripts that build command lines and > runs them. Makes sense. Just to be clear, I'm not advocating running a product for the lit suite, just having one option that controls both dotest and lit. > There is another issue I'm aware of, which is that some people's compilers > have version numbers embedded in the binary name. Right now the code that > uses `LLDB_LIT_TOOLS_DIR` to find the binaries won't handle these cases, > because it looks specifically for `clang` and `clang++`, but not, for > example, `clang-7.0` or `clang++-hexagon-7.0`. How is this handled today? Do we have tests that do something like that? > I do think an iterative approach is better though. This is already a big > change and as this thread (and the previous patch which is what I'm trying to > fix) shows, people use things in a lot of different ways so changing > something has potential for lots of breakage in subtle ways. So I still kind > of prefer doing things incrementally, letting people tell me what's broken, > and then working on a solution. I'm all for iteration! We just wanna make sure we share the same "end goal". > We could try to converge on the single `LLDB_LIT_TOOLS_DIR` approach for both > dotest as well as the lit suite, because having one variable with simple > semantics is nice. But I think we should worry first about getting to a > known good baseline and then working incrementally to make simplifications. I'm worried that the directory approach is incompatible with settings a specific compiler (like gcc). https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54601: Makefile.rules: Use a shared clang module cache directory.
aprantl updated this revision to Diff 174311.
aprantl added a comment.
Small bugfix + an error message that would have caught it.
https://reviews.llvm.org/D54601
Files:
lit/lit.cfg.py
packages/Python/lldbsuite/test/make/Makefile.rules
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -33,7 +33,6 @@
THIS_FILE_DIR := $(shell dirname $(lastword $(MAKEFILE_LIST)))/
LLDB_BASE_DIR := $(THIS_FILE_DIR)../../../../../
-
#--
# If OS is not defined, use 'uname -s' to determine the OS name.
#
@@ -242,7 +241,16 @@
CFLAGS += -gsplit-dwarf
endif
+# Use a shared module cache when building in the default test build directory.
+ifeq "$(findstring lldb-test-build.noindex, $(BUILDDIR))" ""
CLANG_MODULE_CACHE_DIR := $(BUILDDIR)/module-cache
+else
+CLANG_MODULE_CACHE_DIR := $(shell echo "$(BUILDDIR)" | sed
's/lldb-test-build.noindex.*/lldb-test-build.noindex\/module-cache-clang/')
+endif
+
+ifeq "$(CLANG_MODULE_CACHE_DIR)" ""
+$(error failed to set the shared clang module cache dir)
+endif
MANDATORY_MODULE_BUILD_CFLAGS := -fmodules -gmodules
-fmodules-cache-path=$(CLANG_MODULE_CACHE_DIR)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -4,9 +4,9 @@
import sys
import re
import platform
+import shutil
import subprocess
-
import lit.util
import lit.formats
from lit.llvm import llvm_config
@@ -124,3 +124,12 @@
('--build-mode', {'DEBUG': 'debug'}),
('--targets-built', calculate_arch_features)
])
+
+# Clean the module caches in the test build directory. This is
+# necessary in an incremental build whenever clang changes underneath,
+# so doing it once per lit.py invocation is close enough.
+for i in ['module-cache-clang']:
+cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
+if os.path.isdir(cachedir):
+print("Deleting module cache at %s."%cachedir)
+shutil.rmtree(cachedir)
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -33,7 +33,6 @@
THIS_FILE_DIR := $(shell dirname $(lastword $(MAKEFILE_LIST)))/
LLDB_BASE_DIR := $(THIS_FILE_DIR)../../../../../
-
#--
# If OS is not defined, use 'uname -s' to determine the OS name.
#
@@ -242,7 +241,16 @@
CFLAGS += -gsplit-dwarf
endif
+# Use a shared module cache when building in the default test build directory.
+ifeq "$(findstring lldb-test-build.noindex, $(BUILDDIR))" ""
CLANG_MODULE_CACHE_DIR := $(BUILDDIR)/module-cache
+else
+CLANG_MODULE_CACHE_DIR := $(shell echo "$(BUILDDIR)" | sed 's/lldb-test-build.noindex.*/lldb-test-build.noindex\/module-cache-clang/')
+endif
+
+ifeq "$(CLANG_MODULE_CACHE_DIR)" ""
+$(error failed to set the shared clang module cache dir)
+endif
MANDATORY_MODULE_BUILD_CFLAGS := -fmodules -gmodules -fmodules-cache-path=$(CLANG_MODULE_CACHE_DIR)
Index: lit/lit.cfg.py
===
--- lit/lit.cfg.py
+++ lit/lit.cfg.py
@@ -4,9 +4,9 @@
import sys
import re
import platform
+import shutil
import subprocess
-
import lit.util
import lit.formats
from lit.llvm import llvm_config
@@ -124,3 +124,12 @@
('--build-mode', {'DEBUG': 'debug'}),
('--targets-built', calculate_arch_features)
])
+
+# Clean the module caches in the test build directory. This is
+# necessary in an incremental build whenever clang changes underneath,
+# so doing it once per lit.py invocation is close enough.
+for i in ['module-cache-clang']:
+cachedir = os.path.join(config.llvm_obj_root, 'lldb-test-build.noindex', i)
+if os.path.isdir(cachedir):
+print("Deleting module cache at %s."%cachedir)
+shutil.rmtree(cachedir)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54567: Fix LLDB's lit files
zturner added a comment. In https://reviews.llvm.org/D54567#1300641, @JDevlieghere wrote: > In https://reviews.llvm.org/D54567#1300459, @zturner wrote: > > > I'm not sure how hard it would be. > > > > One problem is that dotest supports not just choosing a compiler, but > > choosing multiple compilers, as well as multiple architectures and it runs > > the test suite over the cross product of all of these. That's hard to > > express in CMake. This is why, for example, people end up subverting it > > entirely for productionizing test suite runs, such as what you see on the > > ubuntu bot linked earlier. It doesn't even use the CMake variables for > > running the dotest suite, it just has scripts that build command lines and > > runs them. > > > Makes sense. Just to be clear, I'm not advocating running a product for the > lit suite, just having one option that controls both dotest and lit. > > > There is another issue I'm aware of, which is that some people's compilers > > have version numbers embedded in the binary name. Right now the code that > > uses `LLDB_LIT_TOOLS_DIR` to find the binaries won't handle these cases, > > because it looks specifically for `clang` and `clang++`, but not, for > > example, `clang-7.0` or `clang++-hexagon-7.0`. > > How is this handled today? Do we have tests that do something like that? The tests themselves don't try to do it, usually our tests try to be compiler agnostic, but then people will run the tests with one or more different compilers. I think people use dotest in this manner, by specifying a path to a compiler with a version number in it, but I think it may be all downstream stuff, with no bot coverage. Mostly they do it by specifying `LLDB_TEST_C_COMPILER=/path/to/clang-7.0` or something, and dotest is smart enough to figure this out. We could certainly have this same logic in the lit files though once we get to that point. > > >> I do think an iterative approach is better though. This is already a big >> change and as this thread (and the previous patch which is what I'm trying >> to fix) shows, people use things in a lot of different ways so changing >> something has potential for lots of breakage in subtle ways. So I still >> kind of prefer doing things incrementally, letting people tell me what's >> broken, and then working on a solution. > > I'm all for iteration! We just wanna make sure we share the same "end goal". > >> We could try to converge on the single `LLDB_LIT_TOOLS_DIR` approach for >> both dotest as well as the lit suite, because having one variable with >> simple semantics is nice. But I think we should worry first about getting >> to a known good baseline and then working incrementally to make >> simplifications. > > I'm worried that the directory approach is incompatible with settings a > specific compiler (like gcc). I don't think the directory approach is fundamentally incompatible with using non-clang compilers. But it's important to differentiate what the test suite itself supports and what the test suite supports //when invoked via a CMake-generated target//. That is to say, we don't have to expose all the power of the underlying test suite through CMake. I actually think trying to do so is a mistake, because you're often going to be circumventing it anyway to run the test suite in some special way that wasn't how you configured CMake. dotest.py, for example, takes tons of different command line arguments, many of which are only available if you invoke it directly, as the CMake-generated command line will never use those arguments. So I think this is similar. You can pass arbitrary parameters to lit when you point it to a test directory, so there's fundamental limitation in terms of what's possible this way. Of course, we don't currently //recognize// any, and yes it means you can't specify a specific compiler binary (such as GCC anymore), but I'm not entirely sure how useful that is in the first place, because we're talking about a static CMake configuration. So I think as far as what we expose through CMake, it should be as simple as possible and support the developer use case and the most common buildbot use cases, but more advanced use cases are still supported by directly invoking llvm-lit.py with some special arguments (which we would still need to teach the LLDB lit configuration files to understand). Hopefully this all makes sense. https://reviews.llvm.org/D54567 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r347018 - [NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.
Author: zturner
Date: Thu Nov 15 18:42:32 2018
New Revision: 347018
URL: http://llvm.org/viewvc/llvm-project?rev=347018&view=rev
Log:
[NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.
Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this. For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol. This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?
A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.
With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives. This gives us much better flexibility in
what kinds of symbols the uids can identify.
Added:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.cpp
Modified:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt
lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbUtil.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
Modified: lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt?rev=347018&r1=347017&r2=347018&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/CMakeLists.txt Thu Nov 15
18:42:32 2018
@@ -1,6 +1,7 @@
add_lldb_library(lldbPluginSymbolFileNativePDB PLUGIN
CompileUnitIndex.cpp
PdbIndex.cpp
+ PdbSymUid.cpp
PdbUtil.cpp
SymbolFileNativePDB.cpp
UdtRecordCompleter.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp?rev=347018&r1=347017&r2=347018&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp Thu Nov
15 18:42:32 2018
@@ -108,26 +108,19 @@ static void ParseExtendedInfo(PdbIndex &
}
CompilandIndexItem::CompilandIndexItem(
-PdbSymUid uid, llvm::pdb::ModuleDebugStreamRef debug_stream,
+PdbCompilandId id, llvm::pdb::ModuleDebugStreamRef debug_stream,
llvm::pdb::DbiModuleDescriptor descriptor)
-: m_uid(uid), m_debug_stream(std::move(debug_stream)),
+: m_id(id), m_debug_stream(std::move(debug_stream)),
m_module_descriptor(std::move(descriptor)) {}
CompilandIndexItem &CompileUnitIndex::GetOrCreateCompiland(uint16_t modi) {
- PdbSymUid uid = PdbSymUid::makeCompilandId(modi);
- return GetOrCreateCompiland(uid);
-}
-
-CompilandIndexItem &
-CompileUnitIndex::GetOrCreateCompiland(PdbSymUid compiland_uid) {
- auto result = m_comp_units.try_emplace(compiland_uid.toOpaqueId(), nullptr);
+ auto result = m_comp_units.try_emplace(modi, nullptr);
if (!result.second)
return *result.first->second;
// Find the module list and load its debug information stream and cache it
// since we need to use it for almost all interesting operations.
const DbiModuleList &modules = m_index.dbi().modules();
- uint16_t modi = compiland_uid.asCompiland().modi;
llvm::pdb::DbiModuleDescriptor descriptor =
modules.getModuleDescriptor(modi);
uint16_t stream = descriptor.getModuleStreamIndex();
std::unique_ptr stream_data =
@@ -139,7 +132,7 @@ CompileUnitIndex::GetOrCreateCompiland(P
std::unique_ptr &cci = result.first->second;
cci = llvm::make_unique(
- compiland_uid, std::move(debug_stream), std::move(descriptor));
+ PdbCompilandId{modi}, std::move(debug_stream), std::move(descriptor));
ParseExtendedInfo(m_index, *cci);
cci->m_strings.initialize(debug_stream.getSubsectionsArray());
@@ -172,23 +16
[Lldb-commits] [lldb] r347020 - Don't use uniform initialization syntax.
Author: zturner
Date: Thu Nov 15 19:16:27 2018
New Revision: 347020
URL: http://llvm.org/viewvc/llvm-project?rev=347020&view=rev
Log:
Don't use uniform initialization syntax.
Modified:
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp?rev=347020&r1=347019&r2=347020&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp Thu Nov 15
19:16:27 2018
@@ -134,7 +134,7 @@ void PdbIndex::BuildAddrToSymbolMap(Comp
// We need to add 4 here to adjust for the codeview debug magic
// at the beginning of the debug info stream.
uint32_t sym_offset = iter.offset() + 4;
-PdbCompilandSymId cu_sym_id{modi, sym_offset};
+PdbCompilandSymId cu_sym_id(modi, sym_offset);
// If the debug info is incorrect, we could have multiple symbols with the
// same address. So use try_emplace instead of insert, and the first one
Modified: lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h?rev=347020&r1=347019&r2=347020&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h (original)
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbSymUid.h Thu Nov 15
19:16:27 2018
@@ -43,6 +43,9 @@ struct PdbCompilandId {
};
struct PdbCompilandSymId {
+ PdbCompilandSymId() = default;
+ PdbCompilandSymId(uint16_t modi, uint32_t offset)
+ : modi(modi), offset(offset) {}
// 0-based index of module in PDB
uint16_t modi = 0;
@@ -53,6 +56,10 @@ struct PdbCompilandSymId {
};
struct PdbGlobalSymId {
+ PdbGlobalSymId() = default;
+ PdbGlobalSymId(uint32_t offset, bool is_public)
+ : offset(offset), is_public(is_public) {}
+
// Offset of symbol's record in globals or publics stream.
uint32_t offset = 0;
@@ -62,6 +69,10 @@ struct PdbGlobalSymId {
};
struct PdbTypeSymId {
+ PdbTypeSymId() = default;
+ PdbTypeSymId(llvm::codeview::TypeIndex index, bool is_ipi = false)
+ : index(index), is_ipi(is_ipi) {}
+
// The index of the of the type in the TPI or IPI stream.
llvm::codeview::TypeIndex index;
Modified: lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp?rev=347020&r1=347019&r2=347020&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp Thu
Nov 15 19:16:27 2018
@@ -729,7 +729,7 @@ lldb::FunctionSP SymbolFileNativePDB::Cr
Type *func_type = nullptr;
// FIXME: Resolve types and mangled names.
- PdbTypeSymId sig_id{TypeIndex::None(), false};
+ PdbTypeSymId sig_id(TypeIndex::None(), false);
Mangled mangled(getSymbolName(sym_record));
FunctionSP func_sp = std::make_shared(
sc.comp_unit, toOpaqueUid(func_id), toOpaqueUid(sig_id), mangled,
@@ -830,7 +830,7 @@ lldb::TypeSP SymbolFileNativePDB::Create
}
lldb::TypeSP SymbolFileNativePDB::CreateSimpleType(TypeIndex ti) {
- uint64_t uid = toOpaqueUid(PdbTypeSymId{ti, false});
+ uint64_t uid = toOpaqueUid(PdbTypeSymId(ti, false));
if (ti == TypeIndex::NullptrT()) {
CompilerType ct = m_clang->GetBasicType(eBasicTypeNullPtr);
Declaration decl;
@@ -1163,7 +1163,7 @@ TypeSP SymbolFileNativePDB::CreateAndCac
if (!expected_full_ti)
llvm::consumeError(expected_full_ti.takeError());
else if (*expected_full_ti != type_id.index) {
- full_decl_uid = PdbTypeSymId{*expected_full_ti, false};
+ full_decl_uid = PdbTypeSymId(*expected_full_ti, false);
// It's possible that a lookup would occur for the full decl causing it
// to be cached, then a second lookup would occur for the forward decl.
@@ -1197,7 +1197,6 @@ TypeSP SymbolFileNativePDB::CreateAndCac
m_clang->GetAsTagDecl(result->GetForwardCompilerType());
lldbassert(record_decl);
-TypeIndex ti(type_id.index);
m_uid_to_decl[best_uid] = record_decl;
m_decl_to_status[record_decl] =
DeclStatus(best_uid, Type::eResolveStateForward);
@@ -1343,7 +1342,7 @@ VariableSP SymbolFileNativePDB::CreateGl
}
Declaration decl;
- PdbTypeSymId tid{ti, false};
+ PdbTypeSymId tid(ti, false);
SymbolFileTypeSP type_sp =
std::make_shared(*this, toOpaqueUid(tid));
[Lldb-commits] [PATCH] D54616: [Reproducers] Improve reproducer API and add unit tests.
JDevlieghere created this revision.
JDevlieghere added reviewers: davide, shafik, friss, jingham.
JDevlieghere added a project: LLDB.
Herald added subscribers: abidh, mgorny.
When I landed the initial reproducer framework I knew there were some things
that needed improvement. Rather than bundling it with a patch that adds more
functionality I split it off into this patch. I also think the API is stable
enough to add unit testing, which is included in this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54616
Files:
include/lldb/Core/Debugger.h
include/lldb/Utility/Reproducer.h
source/API/SBDebugger.cpp
source/Commands/CommandObjectReproducer.cpp
source/Core/Debugger.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Utility/Reproducer.cpp
unittests/Utility/CMakeLists.txt
unittests/Utility/ReproducerTest.cpp
Index: unittests/Utility/ReproducerTest.cpp
===
--- /dev/null
+++ unittests/Utility/ReproducerTest.cpp
@@ -0,0 +1,144 @@
+//===-- ReproducerTest.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "gtest/gtest.h"
+
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Reproducer.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+
+class DummyProvider : public repro::Provider {
+public:
+ static constexpr const char *NAME = "dummy";
+
+ DummyProvider(const FileSpec &directory) : Provider(directory) {
+InitializeFileInfo(NAME, {"dummy.yaml"});
+ }
+};
+
+TEST(ReproducerTest, SetCapture) {
+ Reproducer reproducer;
+
+ // Initially both generator and loader are unset.
+ EXPECT_EQ(nullptr, reproducer.GetGenerator());
+ EXPECT_EQ(nullptr, reproducer.GetLoader());
+
+ // Enable capture and check that means we have a generator.
+ {
+auto error = reproducer.SetCapture(true, FileSpec("/bogus/path"));
+EXPECT_FALSE(static_cast(error));
+EXPECT_NE(nullptr, reproducer.GetGenerator());
+
+// Make sure the bogus path is correctly set.
+EXPECT_EQ(FileSpec("/bogus/path"), reproducer.GetGenerator()->GetRoot());
+EXPECT_EQ(FileSpec("/bogus/path"), reproducer.GetReproducerPath());
+ }
+
+ // Ensure that we cannot enable replay.
+ {
+auto error = reproducer.SetReplay(true);
+EXPECT_TRUE(static_cast(error));
+llvm::consumeError(std::move(error));
+EXPECT_EQ(nullptr, reproducer.GetLoader());
+ }
+}
+
+TEST(ReproducerTest, SetReplay) {
+ Reproducer reproducer;
+
+ // Initially both generator and loader are unset.
+ EXPECT_EQ(nullptr, reproducer.GetGenerator());
+ EXPECT_EQ(nullptr, reproducer.GetLoader());
+
+ // Enable capture and check that means we have a generator.
+ {
+auto error = reproducer.SetReplay(true, FileSpec("/bogus/path"));
+// Expected to fail because we can't load the index.
+EXPECT_TRUE(static_cast(error));
+llvm::consumeError(std::move(error));
+// However the loader should still be set, which we check here.
+EXPECT_NE(nullptr, reproducer.GetLoader());
+
+// Make sure the bogus path is correctly set.
+EXPECT_EQ(FileSpec("/bogus/path"), reproducer.GetLoader()->GetRoot());
+EXPECT_EQ(FileSpec("/bogus/path"), reproducer.GetReproducerPath());
+ }
+
+ // Ensure that we cannot enable replay.
+ {
+auto error = reproducer.SetCapture(true);
+EXPECT_TRUE(static_cast(error));
+llvm::consumeError(std::move(error));
+EXPECT_EQ(nullptr, reproducer.GetGenerator());
+ }
+}
+
+TEST(GeneratorTest, ChangeRoot) {
+ Reproducer reproducer;
+
+ auto error = reproducer.SetCapture(true, FileSpec("/bogus/path"));
+ EXPECT_FALSE(static_cast(error));
+ auto &generator = *reproducer.GetGenerator();
+
+ // As long as we haven't registered any providers this should work.
+ generator.ChangeRoot(FileSpec("/other/bogus/path"));
+
+ EXPECT_EQ(FileSpec("/other/bogus/path"),
+reproducer.GetGenerator()->GetRoot());
+ EXPECT_EQ(FileSpec("/other/bogus/path"), reproducer.GetReproducerPath());
+}
+
+TEST(GeneratorTest, Create) {
+ Reproducer reproducer;
+
+ auto error = reproducer.SetCapture(true, FileSpec("/bogus/path"));
+ EXPECT_FALSE(static_cast(error));
+ auto &generator = *reproducer.GetGenerator();
+
+ auto *provider = generator.Create();
+ EXPECT_NE(nullptr, provider);
+ EXPECT_EQ(FileSpec("/bogus/path"), provider->GetRoot());
+ EXPECT_EQ(std::string("dummy"), provider->GetInfo().n
[Lldb-commits] [PATCH] D54617: [wip][Reproducers] Add file provider
JDevlieghere created this revision.
Herald added a subscriber: mgorny.
JDevlieghere added a subscriber: labath.
This patch is WIP and meant to showcase how the reproducer and VFS will
interact.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54617
Files:
include/lldb/Host/FileSystem.h
include/lldb/Utility/FileCollector.h
include/lldb/Utility/Reproducer.h
source/Core/Debugger.cpp
source/Host/common/FileSystem.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Utility/CMakeLists.txt
source/Utility/FileCollector.cpp
source/Utility/Reproducer.cpp
Index: source/Utility/Reproducer.cpp
===
--- source/Utility/Reproducer.cpp
+++ source/Utility/Reproducer.cpp
@@ -187,7 +187,7 @@
return llvm::Error::success();
}
-llvm::Optional Loader::GetProviderInfo(StringRef name) {
+llvm::Optional Loader::GetInfo(StringRef name) {
assert(m_loaded);
auto it = m_provider_info.find(name);
Index: source/Utility/FileCollector.cpp
===
--- /dev/null
+++ source/Utility/FileCollector.cpp
@@ -0,0 +1,134 @@
+//===-- FileCollector.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Utility/FileCollector.h"
+
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+
+using namespace lldb_private;
+using namespace llvm;
+
+static bool IsCaseSensitivePath(StringRef path) {
+ SmallString<256> tmp_dest = path, upper_dest, real_dest;
+
+ // Remove component traversals, links, etc.
+ if (!sys::fs::real_path(path, tmp_dest))
+return true; // Current default value in vfs.yaml
+ path = tmp_dest;
+
+ // Change path to all upper case and ask for its real path, if the latter
+ // exists and is equal to path, it's not case sensitive. Default to case
+ // sensitive in the absence of real_path, since this is the YAMLVFSWriter
+ // default.
+ for (auto &C : path)
+upper_dest.push_back(toUpper(C));
+ if (sys::fs::real_path(upper_dest, real_dest) && path.equals(real_dest))
+return false;
+ return true;
+}
+
+FileCollector::FileCollector(const FileSpec &directory) : m_root(directory) {
+ sys::fs::create_directories(m_root.GetPath(), true);
+}
+
+bool FileCollector::GetRealPath(StringRef src_path,
+SmallVectorImpl &result) {
+ SmallString<256> real_path;
+ StringRef FileName = sys::path::filename(src_path);
+ std::string directory = sys::path::parent_path(src_path).str();
+ auto dir_with_symlink = m_symlink_map.find(directory);
+
+ // Use real_path to fix any symbolic link component present in a path.
+ // Computing the real path is expensive, cache the search through the
+ // parent path directory.
+ if (dir_with_symlink == m_symlink_map.end()) {
+if (!sys::fs::real_path(directory, real_path))
+ return false;
+m_symlink_map[directory] = real_path.str();
+ } else {
+real_path = dir_with_symlink->second;
+ }
+
+ sys::path::append(real_path, FileName);
+ result.swap(real_path);
+ return true;
+}
+
+void FileCollector::AddFile(const Twine &file) {
+ std::lock_guard lock(m_mutex);
+ std::string file_str = file.str();
+ if (MarkAsSeen(file_str))
+AddFileImpl(file_str);
+}
+
+void FileCollector::AddFileImpl(StringRef src_path) {
+ std::string root = m_root.GetPath();
+
+ // We need an absolute src path to append to the root.
+ SmallString<256> absolute_src = src_path;
+ sys::fs::make_absolute(absolute_src);
+
+ // Canonicalize src to a native path to avoid mixed separator styles.
+ sys::path::native(absolute_src);
+
+ // Remove redundant leading "./" pieces and consecutive separators.
+ absolute_src = sys::path::remove_leading_dotslash(absolute_src);
+
+ // Canonicalize the source path by removing "..", "." components.
+ SmallString<256> virtual_path = absolute_src;
+ sys::path::remove_dots(virtual_path, /*remove_dot_dot=*/true);
+
+ // If a ".." component is present after a symlink component, remove_dots may
+ // lead to the wrong real destination path. Let the source be canonicalized
+ // like that but make sure we always use the real path for the destination.
+ SmallString<256> copy_from;
+ if (!GetRealPath(absolute_src, copy_from))
+copy_from = virtual_path;
+
+ SmallString<256> dst_path = StringRef(root);
+ sys::path::append(dst_path, sys::path::relative_path(copy_from));
+
+ // Always map a canonical src path to its real path into the YAML, by doing
+ // this we map different virtual src paths to the same entry in the VFS
+ // overlay, which is a way to emulate symlink inside the VFS; this is also
+ // needed for correctness, not
[Lldb-commits] [PATCH] D54617: [wip][Reproducers] Add file provider
JDevlieghere added a comment. - Initialization of the FS needs to happen in the driver. - All file access has to go through the new FileSystem. - Needs tests. Repository: rLLDB LLDB https://reviews.llvm.org/D54617 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54602: Use a shared module cache directory for LLDB.
davide accepted this revision. davide added a comment. lgtm https://reviews.llvm.org/D54602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
