date:20190716

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor accepted this revision.
teemperor added a comment.
This revision is now accepted and ready to land.

I assume we never tested this and that's how didn't found this in sanitized 
builds?

But this patch LGTM. Thanks Shafik!




Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

JDevlieghere wrote:
> Clang format?
Pretty sure that file is clang-formatted (at least my clang-format doesn't 
modify this file)



Comment at: source/Symbol/ClangASTContext.cpp:1619
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 

JDevlieghere wrote:
> Out of curiosity, who does the cleanup of this pointer? 
It's like an AST object stored in the ASTContext.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-16 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor requested changes to this revision.
teemperor added a comment.
This revision now requires changes to proceed.

On my system clang-format has some complaints, so I think you need to rerun 
clang-format. Probably caused by the rebasing.

I have some minor comments about the TestAST.py (see the inline comments), but 
otherwise this patch LGTM.




Comment at: lldb/packages/Python/lldbsuite/test/lang/c/ast/TestAST.py:1
+"""Test that importing modules in C works as expected."""
+

This comment (and the name of the test class) are copy-pasted from TestCModules 
and should be updated. If we can merge the two test cases (see the inline 
comment below), then this would be fixed as a side-effect.



Comment at: lldb/packages/Python/lldbsuite/test/lang/c/ast/TestAST.py:57
+# This expr command imports __sFILE with definition
+# (FILE is a typedef to __sFILE.)
+self.expect(

I think this test has a good chance to fail once someone 
renamed/removes/changes this internal struct (especially if it's currently  
abstracted with a typedef). Would it be possible to just make a minimal module 
with open and FILE/__sFILE instead? If it's too much trouble, then I'm also 
fine with merging this as-is (as this regression is easy to fix).



Comment at: lldb/packages/Python/lldbsuite/test/lang/c/ast/TestAST.py:67
+# Check that the AST log contains exactly one definition of __sFILE.
+f = open(log_file)
+log_lines = f.readlines()

It seems that this is the only different in the test compared to 
TestCModules.py. Would it be possible to just add this logging/checking to 
TestCModules.py as it's anyway testing something very similar?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61333/new/

https://reviews.llvm.org/D61333



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

[Lldb-commits] [lldb] r366196 - [lldb] Rename Options.inc to CommandOptions.inc [NFC]

2019-07-16 Thread Raphael Isemann via lldb-commits

Author: teemperor
Date: Tue Jul 16 02:27:02 2019
New Revision: 366196

URL: http://llvm.org/viewvc/llvm-project?rev=366196&view=rev
Log:
[lldb] Rename Options.inc to CommandOptions.inc [NFC]

It seems having two Options.inc files in the same project is giving our
custom Xcode project a hard time. This patch renames the new Options.inc
to CommandOptions.inc to prevent this conflict.

Modified:
lldb/trunk/source/Commands/CMakeLists.txt
lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
lldb/trunk/source/Commands/CommandObjectHelp.cpp
lldb/trunk/source/Commands/CommandObjectSettings.cpp
lldb/trunk/source/Commands/CommandObjectTarget.cpp

Modified: lldb/trunk/source/Commands/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CMakeLists.txt?rev=366196&r1=366195&r2=366196&view=diff
==
--- lldb/trunk/source/Commands/CMakeLists.txt (original)
+++ lldb/trunk/source/Commands/CMakeLists.txt Tue Jul 16 02:27:02 2019
@@ -1,4 +1,4 @@
-lldb_tablegen(Options.inc -gen-lldb-option-defs
+lldb_tablegen(CommandOptions.inc -gen-lldb-option-defs
   SOURCE Options.td
   TARGET LLDBOptionsGen)
 

Modified: lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp?rev=366196&r1=366195&r2=366196&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp Tue Jul 16 02:27:02 
2019
@@ -1249,7 +1249,7 @@ static constexpr OptionDefinition g_brea
   // FIXME: We need to add an "internal" command, and then add this sort of
   // thing to it. But I need to see it for now, and don't want to wait.
 #define LLDB_OPTIONS_breakpoint_list
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 #pragma mark List

Modified: lldb/trunk/source/Commands/CommandObjectHelp.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectHelp.cpp?rev=366196&r1=366195&r2=366196&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectHelp.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectHelp.cpp Tue Jul 16 02:27:02 2019
@@ -67,7 +67,7 @@ CommandObjectHelp::~CommandObjectHelp()
 
 static constexpr OptionDefinition g_help_options[] = {
 #define LLDB_OPTIONS_help
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 llvm::ArrayRef

Modified: lldb/trunk/source/Commands/CommandObjectSettings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectSettings.cpp?rev=366196&r1=366195&r2=366196&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectSettings.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectSettings.cpp Tue Jul 16 02:27:02 
2019
@@ -23,7 +23,7 @@ using namespace lldb_private;
 
 static constexpr OptionDefinition g_settings_set_options[] = {
 #define LLDB_OPTIONS_settings_set
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 class CommandObjectSettingsSet : public CommandObjectRaw {
@@ -312,7 +312,7 @@ protected:
 
 static constexpr OptionDefinition g_settings_write_options[] = {
 #define LLDB_OPTIONS_settings_write
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 class CommandObjectSettingsWrite : public CommandObjectParsed {
@@ -435,7 +435,7 @@ private:
 
 static constexpr OptionDefinition g_settings_read_options[] = {
 #define LLDB_OPTIONS_settings_read
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 class CommandObjectSettingsRead : public CommandObjectParsed {

Modified: lldb/trunk/source/Commands/CommandObjectTarget.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectTarget.cpp?rev=366196&r1=366195&r2=366196&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp Tue Jul 16 02:27:02 2019
@@ -1968,7 +1968,7 @@ static constexpr OptionEnumValueElement
 
 static constexpr OptionDefinition g_target_modules_dump_symtab_options[] = {
 #define LLDB_OPTIONS_target_modules_dump_symtab
-#include "Options.inc"
+#include "CommandOptions.inc"
 };
 
 class CommandObjectTargetModulesDumpSymtab


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

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Sorry for the delay. The patch looks fine to me. As far as testing goes, 
there's a "gdb-client" test suite in 
`test/testcases/functionalities/gdb_remote_client/`, which should allow you to 
mock gdb-server responses and verify that the right packets are being sent.




Comment at: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:154
+  ePropertyUseSVR4,
+  ePropertyUseGPacket
 };

I'd add a trailing comma here to avoid changing this line next time we add a 
setting.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931



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

[Lldb-commits] [PATCH] D62570: [WIP] Use LLVM's debug line parser in LLDB

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: lldb/include/lldb/Core/FileSpecList.h:191-192
+  const_iterator end() const { return m_files.end(); }
+  const_iterator begin() { return m_files.begin(); }
+  const_iterator end() { return m_files.end(); }
+

If both of these are returning the const iterators, then you don't need 
non-const versions..



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:804
+  support_files.Append(comp_unit);
+  for (const FileSpec &file : m_support_files[&comp_unit])
+support_files.Append(file);

What's the reason for this global m_support_files map? Is it just because you 
cannot set the "support" file list from inside the `ParseLineTable` call, and 
parsing the line table produces the file list as a "side effect". I've ran into 
the same problem in SymbolFileBreakpad, and I've had to bend over backwards to 
ensure we don't store the file list twice, so maybe it's time to have a more 
general solution to that. I think it would suffice to add 
`CompileUnit::SetSupportFiles` (to complement `CompileUnit::SetLineTable`). 
That way, you could call both `comp_unit->SetSupportFiles` and `->SetLineTable` 
regardless of which one was being asked for.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:832
+#if 0
   // Many type units can share a line table, so parse the support file list
   // once, and cache it based on the offset field.

I guess here you ought to to something similar to the block of code on line 
981. (i.e., parse the line table, fetch files from it, and remap them. The only 
difference would be that you don't use the compilation directory from the type 
unit to resolve relative paths (because type units have no DW_AT_comp_dir).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62570/new/

https://reviews.llvm.org/D62570



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

[Lldb-commits] [PATCH] D64767: [lldb][test_suite] Update tests with unexpected pass on Android aarch64

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Whether a lot of these tests (e.g. all watchpoint related tests) pass or fail 
may depend on the exact android device you are running the tests against. 
However, you are the only ones running android tests ATM, so that does not 
matter much right now. If that ever changes, we'll have to do something smarter 
here...


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64767/new/

https://reviews.llvm.org/D64767



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

[Lldb-commits] [PATCH] D64769: [lldb][test_suite] change the test main.cpp to avoid expression reschedule

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

The change is fine, but for my own education, could you elaborate on what this 
"delayed calculation" is, and how does it make the test fail?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64769/new/

https://reviews.llvm.org/D64769



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

[Lldb-commits] [PATCH] D64782: [SWIG] Deprecate SWIG 1.x

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D64782#1586815 , @JDevlieghere 
wrote:

> I've updated swig on GreenDragon, and the Windows bot is running 3.0. I'm not 
> sure about the Debian bot, as it's incremental it doesn't print the version 
> number. Regardless, I'll keep an eye on the bots of course.

You can see the environment the "debian" bot is running in on it's "buildslave" 
page http://lab.llvm.org:8014/buildslaves/lldb-x86_64-debian. The swig version 
it uses is 3.0.12. The information on that page is hand-populated, so there is 
a danger of it getting out of date, but it should be correct at the moment.

Also, lgtm. :)

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64782/new/

https://reviews.llvm.org/D64782

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

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

teemperor wrote:
> JDevlieghere wrote:
> > Clang format?
> Pretty sure that file is clang-formatted (at least my clang-format doesn't 
> modify this file)
We have a .clang-format file for the test directory which effectively disables 
clang-formatting. So depending on how you run clang-format, the invocation 
might be completely ignored.

The .clang-format was put there before the Great Reformat to avoid it messing 
with the line numbers in tests. Maybe the time has come to do something about 
it...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [lldb] r366213 - [SWIG] Deprecate SWIG 1.x

2019-07-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Tue Jul 16 08:14:01 2019
New Revision: 366213

URL: http://llvm.org/viewvc/llvm-project?rev=366213&view=rev
Log:
[SWIG] Deprecate SWIG 1.x

The last swig 1.x release dates from 2009, now 10 years ago. Recently, I
fixed an issue that prevented us from using swig 4 (r364974), which
turned out to be not backward compatible with swig 1.x (r365718).

This patch deprecates this (really old) version of swig and makes swig 2
the minimum supported version in LLDB . This should be fine for the
build bots, which are all running swig 3 or later.

Differential revision: https://reviews.llvm.org/D64782

Modified:
lldb/trunk/scripts/CMakeLists.txt

Modified: lldb/trunk/scripts/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=366213&r1=366212&r2=366213&view=diff
==
--- lldb/trunk/scripts/CMakeLists.txt (original)
+++ lldb/trunk/scripts/CMakeLists.txt Tue Jul 16 08:14:01 2019
@@ -14,6 +14,11 @@ if(LLDB_BUILD_FRAMEWORK)
 endif()
 
 find_package(SWIG REQUIRED)
+set(SWIG_MIN_VERSION "2.0.0")
+if (${SWIG_VERSION} VERSION_LESS ${SWIG_MIN_VERSION})
+  message(FATAL_ERROR "LLDB requires swig ${SWIG_MIN_VERSION}, your version is 
${SWIG_VERSION}.")
+endif()
+
 add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py


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

[Lldb-commits] [PATCH] D64782: [SWIG] Deprecate SWIG 1.x

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366213: [SWIG] Deprecate SWIG 1.x (authored by JDevlieghere, 
committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64782?vs=210002&id=210103#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64782/new/

https://reviews.llvm.org/D64782

Files:
  lldb/trunk/scripts/CMakeLists.txt


Index: lldb/trunk/scripts/CMakeLists.txt
===
--- lldb/trunk/scripts/CMakeLists.txt
+++ lldb/trunk/scripts/CMakeLists.txt
@@ -14,6 +14,11 @@
 endif()
 
 find_package(SWIG REQUIRED)
+set(SWIG_MIN_VERSION "2.0.0")
+if (${SWIG_VERSION} VERSION_LESS ${SWIG_MIN_VERSION})
+  message(FATAL_ERROR "LLDB requires swig ${SWIG_MIN_VERSION}, your version is 
${SWIG_VERSION}.")
+endif()
+
 add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py


Index: lldb/trunk/scripts/CMakeLists.txt
===
--- lldb/trunk/scripts/CMakeLists.txt
+++ lldb/trunk/scripts/CMakeLists.txt
@@ -14,6 +14,11 @@
 endif()
 
 find_package(SWIG REQUIRED)
+set(SWIG_MIN_VERSION "2.0.0")
+if (${SWIG_VERSION} VERSION_LESS ${SWIG_MIN_VERSION})
+  message(FATAL_ERROR "LLDB requires swig ${SWIG_MIN_VERSION}, your version is ${SWIG_VERSION}.")
+endif()
+
 add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

labath wrote:
> teemperor wrote:
> > JDevlieghere wrote:
> > > Clang format?
> > Pretty sure that file is clang-formatted (at least my clang-format doesn't 
> > modify this file)
> We have a .clang-format file for the test directory which effectively 
> disables clang-formatting. So depending on how you run clang-format, the 
> invocation might be completely ignored.
> 
> The .clang-format was put there before the Great Reformat to avoid it messing 
> with the line numbers in tests. Maybe the time has come to do something about 
> it...
Sounds like a good idea. Most test should be using the `// break here` anyway, 
and removing the special `.clang-format` might flush out the ones that don't. 



Comment at: source/Symbol/ClangASTContext.cpp:1619
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 

teemperor wrote:
> JDevlieghere wrote:
> > Out of curiosity, who does the cleanup of this pointer? 
> It's like an AST object stored in the ASTContext.
Thanks


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [lldb] r366221 - Revert "[swig] Add workaround for old swig"

2019-07-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Tue Jul 16 08:54:33 2019
New Revision: 366221

URL: http://llvm.org/viewvc/llvm-project?rev=366221&view=rev
Log:
Revert "[swig] Add workaround for old swig"

With the deprecation of swig 1.x (r366213), this workaround should no
longer be necessary.

Modified:
lldb/trunk/scripts/interface/SBTypeCategory.i

Modified: lldb/trunk/scripts/interface/SBTypeCategory.i
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/interface/SBTypeCategory.i?rev=366221&r1=366220&r2=366221&view=diff
==
--- lldb/trunk/scripts/interface/SBTypeCategory.i (original)
+++ lldb/trunk/scripts/interface/SBTypeCategory.i Tue Jul 16 08:54:33 2019
@@ -213,11 +213,6 @@ namespace lldb {
 name = property(GetName, None)
 enabled = property(GetEnabled, SetEnabled)
 %}
-#if SWIG_VERSION < 0x030009
-%pythoncode %{
-   __swig_setmethods__["enabled"] = SetEnabled
-%}
-#endif
 
 };
 


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

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

JDevlieghere wrote:
> labath wrote:
> > teemperor wrote:
> > > JDevlieghere wrote:
> > > > Clang format?
> > > Pretty sure that file is clang-formatted (at least my clang-format 
> > > doesn't modify this file)
> > We have a .clang-format file for the test directory which effectively 
> > disables clang-formatting. So depending on how you run clang-format, the 
> > invocation might be completely ignored.
> > 
> > The .clang-format was put there before the Great Reformat to avoid it 
> > messing with the line numbers in tests. Maybe the time has come to do 
> > something about it...
> Sounds like a good idea. Most test should be using the `// break here` 
> anyway, and removing the special `.clang-format` might flush out the ones 
> that don't. 
I'm afraid that won't be enough. All of these tests were using `// break here` 
comments, but that wasn't enough because
```
some(very, long, statement) // break here
```
breaks at a slightly different place than
```
some(very,
  long, statement) // break here
```
Also, things like step-in/over are affected by how lines are broken up, and 
sometimes even comment it self is so long it doesn't fit ("please break on this 
line to inspect the state of foo"). However, I think we could do something via 
some combination of telling clang-format to not break certain comments (there's 
a way to set a regex to match non-breakable comments), increasing the line 
length, and making the comments themselves much shorter...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-16 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz created this revision.
sgraenitz added reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, 
labath, mgorny, jasonmolenda.
Herald added a project: LLDB.

We can always build debugserver, but we can't always sign it to be useable for 
testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the 
system debugserver should be used for testing.
The old behavior complicated the logic around debugserver a lot. The new logic 
sorts out most of it.

Please note that this patch is in early stage and needs some more testing. It 
should not affect platfroms other than Darwin. It builds on Davide's approach 
to validate the code-signing identity at configuration time.

What do you think?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64806

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/CMakeLists.txt
  lldb/tools/debugserver/source/CMakeLists.txt
  lldb/unittests/CMakeLists.txt
  lldb/unittests/tools/lldb-server/CMakeLists.txt

Index: lldb/unittests/tools/lldb-server/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/CMakeLists.txt
+++ lldb/unittests/tools/lldb-server/CMakeLists.txt
@@ -13,10 +13,15 @@
 add_lldb_test_executable(thread_inferior inferior/thread_inferior.cpp)
 add_lldb_test_executable(environment_check inferior/environment_check.cpp)
 
-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(TARGET debugserver)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)
+lldb_find_system_debugserver(debugserver_path)
+  else()
+set(debugserver_path $)
+  endif()
+  add_definitions(-DLLDB_SERVER="${debugserver_path}" -DLLDB_SERVER_IS_DEBUGSERVER=ON)
 else()
-  add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=0)
+  add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=OFF)
 endif()
 
 add_definitions(
Index: lldb/unittests/CMakeLists.txt
===
--- lldb/unittests/CMakeLists.txt
+++ lldb/unittests/CMakeLists.txt
@@ -78,6 +78,6 @@
 add_subdirectory(UnwindAssembly)
 add_subdirectory(Utility)
 
-if(LLDB_CAN_USE_DEBUGSERVER AND NOT SKIP_TEST_DEBUGSERVER)
+if(LLDB_CAN_USE_DEBUGSERVER AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
Index: lldb/tools/debugserver/source/CMakeLists.txt
===
--- lldb/tools/debugserver/source/CMakeLists.txt
+++ lldb/tools/debugserver/source/CMakeLists.txt
@@ -6,6 +6,58 @@
 
 include_directories(MacOSX)
 
+function(check_certificate identity result_valid)
+  execute_process(
+COMMAND security find-certificate -Z -p -c ${identity} /Library/Keychains/System.keychain
+RESULT_VARIABLE exit_code OUTPUT_QUIET ERROR_QUIET)
+  if(exit_code)
+set(${result_valid} FALSE PARENT_SCOPE)
+  else()
+set(${result_valid} TRUE PARENT_SCOPE)
+  endif()
+endfunction()
+
+function(get_debugserver_codesign_identity result)
+  string(CONCAT not_found_help
+"This will cause failures in the test suite."
+"Pass '-DLLDB_USE_SYSTEM_DEBUGSERVER=ON' to use the system one instead."
+"See 'Code Signing on macOS' in the documentation."
+  )
+
+  # Explicit override: warn if unavailable
+  if(LLDB_CODESIGN_IDENTITY)
+set(${result} ${LLDB_CODESIGN_IDENTITY} PARENT_SCOPE)
+check_certificate(${LLDB_CODESIGN_IDENTITY} available)
+if(NOT available AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+  message(WARNING "LLDB_CODESIGN_IDENTITY not found: '${LLDB_CODESIGN_IDENTITY}' ${not_found_help}")
+endif()
+return()
+  endif()
+
+  # Development signing identity: use if available
+  check_certificate(lldb_codesign available)
+  if(available)
+set(${result} lldb_codesign PARENT_SCOPE)
+return()
+  endif()
+
+  if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+message(WARNING "Development code sign identiy not found: 'lldb_codesign' ${not_found_help}")
+  endif()
+
+  # LLVM pendant: fallback if available
+  if(LLVM_CODESIGNING_IDENTITY)
+check_certificate(${LLVM_CODESIGNING_IDENTITY} available)
+if(available)
+  set(${result} ${LLVM_CODESIGNING_IDENTITY} PARENT_SCOPE)
+  return()
+endif()
+  endif()
+
+  # Ad-hoc signing: last resort
+  set(${result} "-" PARENT_SCOPE)
+endfunction()
+
 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_SOURCE_DIR}/../resources/lldb-debugserver-Info.plist")
 
 check_cxx_compiler_flag("-Wno-gnu-zero-variadic-macro-arguments"
@@ -30,132 +82,17 @@
 
 add_subdirectory(MacOSX)
 
-# LLDB-specific identity, currently used for code signing debugserver.
 set(LLDB_CODESIGN_IDENTITY "" CACHE STRING
-"Override code sign identity for debugserver and for use in tests; falls back to LLVM_CODESIGNING_IDENTITY if set or lldb_codesign otherwise (Darwin only)")
-
-# Determine which ident

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik marked 5 inline comments as done.
shafik added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

labath wrote:
> JDevlieghere wrote:
> > labath wrote:
> > > teemperor wrote:
> > > > JDevlieghere wrote:
> > > > > Clang format?
> > > > Pretty sure that file is clang-formatted (at least my clang-format 
> > > > doesn't modify this file)
> > > We have a .clang-format file for the test directory which effectively 
> > > disables clang-formatting. So depending on how you run clang-format, the 
> > > invocation might be completely ignored.
> > > 
> > > The .clang-format was put there before the Great Reformat to avoid it 
> > > messing with the line numbers in tests. Maybe the time has come to do 
> > > something about it...
> > Sounds like a good idea. Most test should be using the `// break here` 
> > anyway, and removing the special `.clang-format` might flush out the ones 
> > that don't. 
> I'm afraid that won't be enough. All of these tests were using `// break 
> here` comments, but that wasn't enough because
> ```
> some(very, long, statement) // break here
> ```
> breaks at a slightly different place than
> ```
> some(very,
>   long, statement) // break here
> ```
> Also, things like step-in/over are affected by how lines are broken up, and 
> sometimes even comment it self is so long it doesn't fit ("please break on 
> this line to inspect the state of foo"). However, I think we could do 
> something via some combination of telling clang-format to not break certain 
> comments (there's a way to set a regex to match non-breakable comments), 
> increasing the line length, and making the comments themselves much shorter...
Ahhh that makes sense, I was going to reply the same way @teemperor did.



Comment at: source/Symbol/ClangASTContext.cpp:1619
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 

JDevlieghere wrote:
> teemperor wrote:
> > JDevlieghere wrote:
> > > Out of curiosity, who does the cleanup of this pointer? 
> > It's like an AST object stored in the ASTContext.
> Thanks
If you dig into the `CreateCopy` it does a `Context.Allocate` and these 
allocations will be released when the `ASTContext` is destroyed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-16 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz updated this revision to Diff 210124.
sgraenitz added a comment.

Minor fixes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64806/new/

https://reviews.llvm.org/D64806

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/CMakeLists.txt
  lldb/tools/debugserver/source/CMakeLists.txt
  lldb/unittests/CMakeLists.txt
  lldb/unittests/tools/lldb-server/CMakeLists.txt

Index: lldb/unittests/tools/lldb-server/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/CMakeLists.txt
+++ lldb/unittests/tools/lldb-server/CMakeLists.txt
@@ -13,10 +13,16 @@
 add_lldb_test_executable(thread_inferior inferior/thread_inferior.cpp)
 add_lldb_test_executable(environment_check inferior/environment_check.cpp)
 
-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(LLDB_CAN_USE_LLDB_SERVER)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)
+lldb_find_system_debugserver(system_debugserver_path)
+add_definitions(-DLLDB_SERVER="${system_debugserver_path}")
+  else()
+add_definitions(-DLLDB_SERVER="$")
+  endif()
+  add_definitions(-DLLDB_SERVER_IS_DEBUGSERVER=ON)
 else()
-  add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=0)
+  add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=OFF)
 endif()
 
 add_definitions(
Index: lldb/unittests/CMakeLists.txt
===
--- lldb/unittests/CMakeLists.txt
+++ lldb/unittests/CMakeLists.txt
@@ -78,6 +78,6 @@
 add_subdirectory(UnwindAssembly)
 add_subdirectory(Utility)
 
-if(LLDB_CAN_USE_DEBUGSERVER AND NOT SKIP_TEST_DEBUGSERVER)
+if(LLDB_CAN_USE_DEBUGSERVER AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
Index: lldb/tools/debugserver/source/CMakeLists.txt
===
--- lldb/tools/debugserver/source/CMakeLists.txt
+++ lldb/tools/debugserver/source/CMakeLists.txt
@@ -6,6 +6,58 @@
 
 include_directories(MacOSX)
 
+function(check_certificate identity result_valid)
+  execute_process(
+COMMAND security find-certificate -Z -p -c ${identity} /Library/Keychains/System.keychain
+RESULT_VARIABLE exit_code OUTPUT_QUIET ERROR_QUIET)
+  if(exit_code)
+set(${result_valid} FALSE PARENT_SCOPE)
+  else()
+set(${result_valid} TRUE PARENT_SCOPE)
+  endif()
+endfunction()
+
+function(get_debugserver_codesign_identity result)
+  string(CONCAT not_found_help
+"This will cause failures in the test suite."
+"Pass '-DLLDB_USE_SYSTEM_DEBUGSERVER=ON' to use the system one instead."
+"See 'Code Signing on macOS' in the documentation."
+  )
+
+  # Explicit override: always use it, but warn if unavailable and used for testing
+  if(LLDB_CODESIGN_IDENTITY)
+set(${result} ${LLDB_CODESIGN_IDENTITY} PARENT_SCOPE)
+check_certificate(${LLDB_CODESIGN_IDENTITY} available)
+if(NOT available AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+  message(WARNING "LLDB_CODESIGN_IDENTITY not found: '${LLDB_CODESIGN_IDENTITY}' ${not_found_help}")
+endif()
+return()
+  endif()
+
+  # Development signing identity: use if available
+  check_certificate(lldb_codesign available)
+  if(available)
+set(${result} lldb_codesign PARENT_SCOPE)
+return()
+  endif()
+
+  if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+message(WARNING "Development code sign identiy not found: 'lldb_codesign' ${not_found_help}")
+  endif()
+
+  # LLVM pendant: fallback if available
+  if(LLVM_CODESIGNING_IDENTITY)
+check_certificate(${LLVM_CODESIGNING_IDENTITY} available)
+if(available)
+  set(${result} ${LLVM_CODESIGNING_IDENTITY} PARENT_SCOPE)
+  return()
+endif()
+  endif()
+
+  # Ad-hoc signing: last resort
+  set(${result} "-" PARENT_SCOPE)
+endfunction()
+
 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_SOURCE_DIR}/../resources/lldb-debugserver-Info.plist")
 
 check_cxx_compiler_flag("-Wno-gnu-zero-variadic-macro-arguments"
@@ -30,132 +82,17 @@
 
 add_subdirectory(MacOSX)
 
-# LLDB-specific identity, currently used for code signing debugserver.
 set(LLDB_CODESIGN_IDENTITY "" CACHE STRING
-"Override code sign identity for debugserver and for use in tests; falls back to LLVM_CODESIGNING_IDENTITY if set or lldb_codesign otherwise (Darwin only)")
-
-# Determine which identity to use and store it in the separate cache entry.
-# We will query it later for LLDB_TEST_COMMON_ARGS.
-if(LLDB_CODESIGN_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLDB_CODESIGN_IDENTITY} CACHE INTERNAL "" FORCE)
-elseif(LLVM_CODESIGNING_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLVM_CODESIGNING_IDENTITY} CACHE INTERNAL "" FORCE)
-else()
-  set(LLDB_CODESIGN_IDENTITY_USED lldb_codesign CACHE INTERNAL "" FORCE)
-endif()
+"Identity override for debug

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-16 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz marked 3 inline comments as done.
sgraenitz added inline comments.



Comment at: lldb/CMakeLists.txt:94
-  endif()
-
   if(TARGET lldb-mi)

The target will always exist now. The dependency would now depend on 
`LLDB_USE_SYSTEM_DEBUGSERVER` and set in `lldb/test/CMakeLists.txt`.



Comment at: lldb/tools/debugserver/source/CMakeLists.txt:86
 set(LLDB_CODESIGN_IDENTITY "" CACHE STRING
-"Override code sign identity for debugserver and for use in tests; falls 
back to LLVM_CODESIGNING_IDENTITY if set or lldb_codesign otherwise (Darwin 
only)")
-
-# Determine which identity to use and store it in the separate cache entry.
-# We will query it later for LLDB_TEST_COMMON_ARGS.
-if(LLDB_CODESIGN_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLDB_CODESIGN_IDENTITY} CACHE INTERNAL "" 
FORCE)
-elseif(LLVM_CODESIGNING_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLVM_CODESIGNING_IDENTITY} CACHE INTERNAL 
"" FORCE)
-else()
-  set(LLDB_CODESIGN_IDENTITY_USED lldb_codesign CACHE INTERNAL "" FORCE)
-endif()
+"Identity override for debugserver; see 'Code Signing on macOS' in the 
documentation (Darwin only)")
 

The option may move to `LLDBConfig.cmake`? Actually, it affects not only the 
debugserver target, but also test configuration.



Comment at: lldb/tools/debugserver/source/CMakeLists.txt:258
   endif()
-endif()
+#endif()

Removing the `if() ... endif()` would bloat the diff even more. Would do it in 
a follow-up NFC commit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64806/new/

https://reviews.llvm.org/D64806



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

[Lldb-commits] [lldb] r366226 - [CMake] Add Apple-lldb-Xcode.cmake cache that avoids install options

2019-07-16 Thread Stefan Granitz via lldb-commits

Author: stefan.graenitz
Date: Tue Jul 16 09:57:45 2019
New Revision: 366226

URL: http://llvm.org/viewvc/llvm-project?rev=366226&view=rev
Log:
[CMake] Add Apple-lldb-Xcode.cmake cache that avoids install options

Added:
lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake

Added: lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake?rev=366226&view=auto
==
--- lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake (added)
+++ lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake Tue Jul 16 09:57:45 2019
@@ -0,0 +1,4 @@
+include(${CMAKE_CURRENT_LIST_DIR}/Apple-lldb-base.cmake)
+
+set(LLDB_BUILD_FRAMEWORK ON CACHE BOOL "")
+set(CMAKE_OSX_DEPLOYMENT_TARGET 10.11 CACHE STRING "")


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

[Lldb-commits] [PATCH] D64536: Adding inline comments to code view type records

2019-07-16 Thread NILANJANA BASU via Phabricator via lldb-commits

nilanjana_basu updated this revision to Diff 210123.
nilanjana_basu added a comment.

Corrected comments for codeview type record from "NumAttributes" to 
"AccessSpecifier"


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64536/new/

https://reviews.llvm.org/D64536

Files:
  llvm/include/llvm/DebugInfo/CodeView/CodeViewRecordIO.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/DebugInfo/CodeView/CodeViewRecordIO.cpp
  llvm/lib/DebugInfo/CodeView/TypeRecordMapping.cpp
  llvm/test/DebugInfo/COFF/types-basic.ll

Index: llvm/test/DebugInfo/COFF/types-basic.ll
===
--- llvm/test/DebugInfo/COFF/types-basic.ll
+++ llvm/test/DebugInfo/COFF/types-basic.ll
@@ -347,17 +347,15 @@
 ; CHECK:   ]
 ; CHECK: ]
 
-
-
 ; ASM: .section	.debug$T,"dr"
 ; ASM: .p2align	2
 ; ASM: .long	4   # Debug section magic
 ; ASM: .short	18
 ; ASM: .short	4609
-; ASM: .long	3
-; ASM: .long	64
-; ASM: .long	65
-; ASM: .long	19
+; ASM: .long	3   # NumArgs
+; ASM: .long	64  # Argument
+; ASM: .long	65  # Argument
+; ASM: .long	19  # Argument
 ; ASM: # ArgList (0x1000) {
 ; ASM: #   TypeLeafKind: LF_ARGLIST (0x1201)
 ; ASM: #   NumArgs: 3
@@ -369,11 +367,11 @@
 ; ASM: # }
 ; ASM: .short	14
 ; ASM: .short	4104
-; ASM: .long	3
-; ASM: .byte	0
-; ASM: .byte	0
-; ASM: .short	3
-; ASM: .long	4096
+; ASM: .long	3   # ReturnType
+; ASM: .byte	0   # CallingConvention
+; ASM: .byte	0   # FunctionOptions
+; ASM: .short	3   # NumParameters
+; ASM: .long	4096# ArgListType
 ; ASM: # Procedure (0x1001) {
 ; ASM: #   TypeLeafKind: LF_PROCEDURE (0x1008)
 ; ASM: #   ReturnType: void (0x3)
@@ -385,9 +383,9 @@
 ; ASM: # }
 ; ASM: .short	14
 ; ASM: .short	5633
-; ASM: .long	0
-; ASM: .long	4097
-; ASM: .asciz	"f"
+; ASM: .long	0   # ParentScope
+; ASM: .long	4097# FunctionType
+; ASM: .asciz	"f" # Name
 ; ASM: .byte	242
 ; ASM: .byte	241
 ; ASM: # FuncId (0x1002) {
@@ -398,8 +396,8 @@
 ; ASM: # }
 ; ASM: .short	10
 ; ASM: .short	4097
-; ASM: .long	116
-; ASM: .short	1
+; ASM: .long	116 # ModifiedType
+; ASM: .short	1   # Modifiers
 ; ASM: .byte	242
 ; ASM: .byte	241
 ; ASM: # Modifier (0x1003) {
@@ -411,8 +409,8 @@
 ; ASM: # }
 ; ASM: .short	10
 ; ASM: .short	4098
-; ASM: .long	4099
-; ASM: .long	65548
+; ASM: .long	4099# PointeeType
+; ASM: .long	65548   # Attributes
 ; ASM: # Pointer (0x1004) {
 ; ASM: #   TypeLeafKind: LF_POINTER (0x1002)
 ; ASM: #   PointeeType: const int (0x1003)
@@ -429,13 +427,13 @@
 ; ASM: # }
 ; ASM: .short	22
 ; ASM: .short	5381
-; ASM: .short	0
-; ASM: .short	128
-; ASM: .long	0
-; ASM: .long	0
-; ASM: .long	0
-; ASM: .short	0
-; ASM: .asciz	"A"
+; ASM: .short	0   # MemberCount
+; ASM: .short	128 # Properties
+; ASM: .long	0   # FieldList
+; ASM: .long	0   # DerivedFrom
+; ASM: .long	0   # VShape
+; ASM: .short	0   # SizeOf
+; ASM: .asciz	"A" # Name
 ; ASM: # Struct (0x1005) {
 ; ASM: #   TypeLeafKind: LF_STRUCTURE (0x1505)
 ; ASM: #   MemberCount: 0
@@ -450,10 +448,10 @@
 ; ASM: # }
 ; ASM: .short	18
 ; ASM: .short	4098
-; ASM: .long	116
-; ASM: .long	32844
-; ASM: .long	4101
-; ASM: .short	4
+; ASM: .long	116 # PointeeType
+; ASM: .long	32844   # Attributes
+; ASM: .long	4101# ClassType
+; ASM: .short	4   # Representation
 ; ASM: .byte	242
 ; ASM: .byte	241
 ; ASM: # Pointer (0x1006) {
@@ -474,8 +472,8 @@
 ; ASM: # }
 ; ASM: .short	10
 ; ASM: .short	4098
-; ASM: .long	4101
-; ASM: .long	66572
+; ASM: .long	4101# PointeeType
+; ASM: .long	66572   # Attributes
 ; ASM: # Pointer (0x1007) {
 ; ASM: #   TypeLeafKind: LF_POINTER (0x1002)
 ; ASM: #   PointeeType: A (0x1005)
@@ -492,7 +490,7 @@
 ; ASM: # }
 ; ASM: .short	6
 ; ASM: .short	4609
-; ASM: .long	0
+; ASM: .long	0   # NumArgs
 ; ASM: # ArgList (0x1008) {
 ; ASM: #   TypeLeafKind: LF_ARGLIST (0x1201)
 ; ASM: #   NumArgs: 0
@@ -501,14 +499,14 @@
 ; ASM: # }
 ; ASM: .short	26
 ; ASM: .short	4105
-; ASM: .long	3
-; ASM: .long	4101
-; ASM: .long	4103
-; ASM: .byte	0
-; ASM: .byte	0
-; ASM: .short	0
-; ASM: .long	4104
-; ASM: .long	0
+; ASM: .long	3   # ReturnType
+; ASM: .long	4101# ClassType
+; ASM: .long	4103# ThisType
+; ASM: .byte	0   # CallingConvention
+; ASM: .byte	0   # FunctionOptions
+; ASM: .short	0   # NumParameters
+; ASM: .long	4104# ArgLi

[Lldb-commits] [PATCH] D63813: Adjust variable formatting table

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Lukas, do you have commit access or do you need one of us to land this for you?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63813/new/

https://reviews.llvm.org/D63813



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

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp:1
+template 
+struct M {};

shafik wrote:
> labath wrote:
> > JDevlieghere wrote:
> > > labath wrote:
> > > > teemperor wrote:
> > > > > JDevlieghere wrote:
> > > > > > Clang format?
> > > > > Pretty sure that file is clang-formatted (at least my clang-format 
> > > > > doesn't modify this file)
> > > > We have a .clang-format file for the test directory which effectively 
> > > > disables clang-formatting. So depending on how you run clang-format, 
> > > > the invocation might be completely ignored.
> > > > 
> > > > The .clang-format was put there before the Great Reformat to avoid it 
> > > > messing with the line numbers in tests. Maybe the time has come to do 
> > > > something about it...
> > > Sounds like a good idea. Most test should be using the `// break here` 
> > > anyway, and removing the special `.clang-format` might flush out the ones 
> > > that don't. 
> > I'm afraid that won't be enough. All of these tests were using `// break 
> > here` comments, but that wasn't enough because
> > ```
> > some(very, long, statement) // break here
> > ```
> > breaks at a slightly different place than
> > ```
> > some(very,
> >   long, statement) // break here
> > ```
> > Also, things like step-in/over are affected by how lines are broken up, and 
> > sometimes even comment it self is so long it doesn't fit ("please break on 
> > this line to inspect the state of foo"). However, I think we could do 
> > something via some combination of telling clang-format to not break certain 
> > comments (there's a way to set a regex to match non-breakable comments), 
> > increasing the line length, and making the comments themselves much 
> > shorter...
> Ahhh that makes sense, I was going to reply the same way @teemperor did.
Oh, I was totally unaware of that. That probably means I should double-check if 
some of my tests were actually clang-formatted :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777



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

[Lldb-commits] [PATCH] D64769: [lldb][test_suite] change the test main.cpp to avoid expression reschedule

2019-07-16 Thread Wanyi Ye via Phabricator via lldb-commits

kusmour added a comment.

In D64769#1587318 , @labath wrote:

> The change is fine, but for my own education, could you elaborate on what 
> this "delayed calculation" is, and how does it make the test fail?

The test set the breakpoint to the return statement, even thought the compiler 
flag `-O0` was set, the first hit to that bp showed that `g_common_1 = 0` which 
actually should be 21. The test assume when we hit the return statement, the 
value should already be calculated, but that's not the case for NDK20 clang.

So we reproduce the test manually, turned out that the value was calculated 
later. lldb first hit the return statement then jump back to line 20. By 
looking at the assembly that clang provided, it indeed jump back and forth.

It's possible that the jumping behavior is caused by optimization, considering 
there're some other tests having similar problem, and the behavior changed a 
lot from NDK 19 to 20. I made this change because this is irrelevant to testing 
global variables.

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64769/new/

https://reviews.llvm.org/D64769

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

[Lldb-commits] [PATCH] D64767: [lldb][test_suite] Update tests with unexpected pass on Android aarch64

2019-07-16 Thread Wanyi Ye via Phabricator via lldb-commits

kusmour added a comment.

In D64767#1587311 , @labath wrote:

> Whether a lot of these tests (e.g. all watchpoint related tests) pass or fail 
> may depend on the exact android device you are running the tests against. 
> However, you are the only ones running android tests ATM, so that does not 
> matter much right now. If that ever changes, we'll have to do something 
> smarter here...


Thank you very much! I will test on more devices later.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64767/new/

https://reviews.llvm.org/D64767



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: sgraenitz, labath, xiaobai.
JDevlieghere added a project: LLDB.
Herald added a subscriber: mgorny.

Because of how CMake finds the Python libraries and interpreter, it's possible 
to end up with a discrepancy between the two. For example, you'd end up using a 
Python 3 interpreter to run the test suite while LLDB was build and linked 
against Python 2. This patch adds a CMake warning so we find out at 
configuration time, instead of finding out at test time, after having build 
LLDB.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64812

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -185,7 +185,6 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
 
@@ -194,8 +193,12 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp)
-find_package(PythonLibs)
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+
+  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING)
+message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
   endif()
 
   if (PYTHON_INCLUDE_DIR)


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -185,7 +185,6 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
 
@@ -194,8 +193,12 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp)
-find_package(PythonLibs)
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+
+  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING)
+message(FATAL_ERROR "Found incompatible Python interpreter (${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
   endif()
 
   if (PYTHON_INCLUDE_DIR)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Alex Langford via Phabricator via lldb-commits

xiaobai accepted this revision.
xiaobai added a comment.
This revision is now accepted and ready to land.

This definitely caused me some pain a few months ago. Thanks for adding this!


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [lldb] r366243 - [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Tue Jul 16 11:27:12 2019
New Revision: 366243

URL: http://llvm.org/viewvc/llvm-project?rev=366243&view=rev
Log:
[CMake] Fail when Python interpreter doesn't match Python libraries version

Because of how CMake finds the Python libraries and interpreter, it's
possible to end up with a discrepancy between the two. For example,
you'd end up using a Python 3 interpreter to run the test suite while
LLDB was built and linked against Python 2.

This patch adds a fatal error to CMake so we find out at configuration
time, instead of finding out at test time.

Differential revision: https://reviews.llvm.org/D64812

Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=366243&r1=366242&r2=366243&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Tue Jul 16 11:27:12 2019
@@ -185,7 +185,6 @@ function(find_python_libs_windows)
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
 
@@ -194,8 +193,12 @@ if (NOT LLDB_DISABLE_PYTHON)
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp)
-find_package(PythonLibs)
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+
+  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING)
+message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
   endif()
 
   if (PYTHON_INCLUDE_DIR)


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

[Lldb-commits] [PATCH] D64536: Adding inline comments to code view type records

2019-07-16 Thread NILANJANA BASU via Phabricator via lldb-commits

nilanjana_basu updated this revision to Diff 210142.
nilanjana_basu added a comment.

Added record kind name in the comments for better readability


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64536/new/

https://reviews.llvm.org/D64536

Files:
  llvm/include/llvm/DebugInfo/CodeView/CodeViewRecordIO.h
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/DebugInfo/CodeView/CodeViewRecordIO.cpp
  llvm/lib/DebugInfo/CodeView/TypeRecordMapping.cpp
  llvm/test/DebugInfo/COFF/types-basic.ll

Index: llvm/test/DebugInfo/COFF/types-basic.ll
===
--- llvm/test/DebugInfo/COFF/types-basic.ll
+++ llvm/test/DebugInfo/COFF/types-basic.ll
@@ -347,17 +347,15 @@
 ; CHECK:   ]
 ; CHECK: ]
 
-
-
 ; ASM: .section	.debug$T,"dr"
 ; ASM: .p2align	2
 ; ASM: .long	4   # Debug section magic
-; ASM: .short	18
-; ASM: .short	4609
-; ASM: .long	3
-; ASM: .long	64
-; ASM: .long	65
-; ASM: .long	19
+; ASM: .short	18  # Record length
+; ASM: .short	4609# Record kind: LF_ARGLIST
+; ASM: .long	3   # NumArgs
+; ASM: .long	64  # Argument
+; ASM: .long	65  # Argument
+; ASM: .long	19  # Argument
 ; ASM: # ArgList (0x1000) {
 ; ASM: #   TypeLeafKind: LF_ARGLIST (0x1201)
 ; ASM: #   NumArgs: 3
@@ -367,13 +365,13 @@
 ; ASM: # ArgType: __int64 (0x13)
 ; ASM: #   ]
 ; ASM: # }
-; ASM: .short	14
-; ASM: .short	4104
-; ASM: .long	3
-; ASM: .byte	0
-; ASM: .byte	0
-; ASM: .short	3
-; ASM: .long	4096
+; ASM: .short	14  # Record length
+; ASM: .short	4104# Record kind: LF_PROCEDURE
+; ASM: .long	3   # ReturnType
+; ASM: .byte	0   # CallingConvention
+; ASM: .byte	0   # FunctionOptions
+; ASM: .short	3   # NumParameters
+; ASM: .long	4096# ArgListType
 ; ASM: # Procedure (0x1001) {
 ; ASM: #   TypeLeafKind: LF_PROCEDURE (0x1008)
 ; ASM: #   ReturnType: void (0x3)
@@ -383,11 +381,11 @@
 ; ASM: #   NumParameters: 3
 ; ASM: #   ArgListType: (float, double, __int64) (0x1000)
 ; ASM: # }
-; ASM: .short	14
-; ASM: .short	5633
-; ASM: .long	0
-; ASM: .long	4097
-; ASM: .asciz	"f"
+; ASM: .short	14  # Record length
+; ASM: .short	5633# Record kind: LF_FUNC_ID
+; ASM: .long	0   # ParentScope
+; ASM: .long	4097# FunctionType
+; ASM: .asciz	"f" # Name
 ; ASM: .byte	242
 ; ASM: .byte	241
 ; ASM: # FuncId (0x1002) {
@@ -396,10 +394,10 @@
 ; ASM: #   FunctionType: void (float, double, __int64) (0x1001)
 ; ASM: #   Name: f
 ; ASM: # }
-; ASM: .short	10
-; ASM: .short	4097
-; ASM: .long	116
-; ASM: .short	1
+; ASM: .short	10  # Record length
+; ASM: .short	4097# Record kind: LF_MODIFIER
+; ASM: .long	116 # ModifiedType
+; ASM: .short	1   # Modifiers
 ; ASM: .byte	242
 ; ASM: .byte	241
 ; ASM: # Modifier (0x1003) {
@@ -409,10 +407,10 @@
 ; ASM: # Const (0x1)
 ; ASM: #   ]
 ; ASM: # }
-; ASM: .short	10
-; ASM: .short	4098
-; ASM: .long	4099
-; ASM: .long	65548
+; ASM: .short	10  # Record length
+; ASM: .short	4098# Record kind: LF_POINTER
+; ASM: .long	4099# PointeeType
+; ASM: .long	65548   # Attributes
 ; ASM: # Pointer (0x1004) {
 ; ASM: #   TypeLeafKind: LF_POINTER (0x1002)
 ; ASM: #   PointeeType: const int (0x1003)
@@ -427,15 +425,15 @@
 ; ASM: #   IsThisPtr&&: 0
 ; ASM: #   SizeOf: 8
 ; ASM: # }
-; ASM: .short	22
-; ASM: .short	5381
-; ASM: .short	0
-; ASM: .short	128
-; ASM: .long	0
-; ASM: .long	0
-; ASM: .long	0
-; ASM: .short	0
-; ASM: .asciz	"A"
+; ASM: .short	22  # Record length
+; ASM: .short	5381# Record kind: LF_STRUCTURE
+; ASM: .short	0   # MemberCount
+; ASM: .short	128 # Properties
+; ASM: .long	0   # FieldList
+; ASM: .long	0   # DerivedFrom
+; ASM: .long	0   # VShape
+; ASM: .short	0   # SizeOf
+; ASM: .asciz	"A" # Name
 ; ASM: # Struct (0x1005) {
 ; ASM: #   TypeLeafKind: LF_STRUCTURE (0x1505)
 ; ASM: #   MemberCount: 0
@@ -448,12 +446,12 @@
 ; ASM: #   SizeOf: 0
 ; ASM: #   Name: A
 ; ASM: # }
-; ASM: .short	18
-; ASM: .short	4098
-; ASM: .long	116
-; ASM: .long	32844
-; ASM: .long	4101
-; ASM: .short	4
+; ASM: .short	18  # Record length
+; ASM: .short	4098# Record kind: LF_POINTER
+; ASM: .long	116 # PointeeType
+; ASM: .long	32844   # Attributes
+; ASM: .long	4101# ClassType
+; ASM: .short	4   # Representation
 ; ASM: .by

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

Hmm, I've just looked through CMake docs, and I think a better solution might 
be:

  find_package(Python COMPONENTS Interpreter Development)

Apparently using separate modules has been deprecated in 3.12, and using a 
single `FindPython` call guarantees version match.

Of course, this would require changing all the stuff that relies on Python. if 
you don't have time to fight it, I suppose this is good enough as interim 
solution.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366243: [CMake] Fail when Python interpreter doesn't 
match Python libraries version (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64812?vs=210140&id=210143#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812

Files:
  lldb/trunk/cmake/modules/LLDBConfig.cmake


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -185,7 +185,6 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
 
@@ -194,8 +193,12 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp)
-find_package(PythonLibs)
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+
+  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING)
+message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
   endif()
 
   if (PYTHON_INCLUDE_DIR)


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -185,7 +185,6 @@
 endfunction(find_python_libs_windows)
 
 if (NOT LLDB_DISABLE_PYTHON)
-
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
 
@@ -194,8 +193,12 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp)
-find_package(PythonLibs)
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+
+  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING)
+message(FATAL_ERROR "Found incompatible Python interpreter (${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
   endif()
 
   if (PYTHON_INCLUDE_DIR)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D64812#1588030 , @mgorny wrote:

> Hmm, I've just looked through CMake docs, and I think a better solution might 
> be:
>
>   find_package(Python COMPONENTS Interpreter Development)
>
>
> Apparently using separate modules has been deprecated in 3.12, and using a 
> single `FindPython` call guarantees version match.
>
> Of course, this would require changing all the stuff that relies on Python. 
> if you don't have time to fight it, I suppose this is good enough as interim 
> solution.


If that works in `3.4` I'm happy to go that way!


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Reid Kleckner via Phabricator via lldb-commits

rnk added a comment.

You broke my build. =/ I got this output:

  CMake Error at C:/src/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:201 
(message):
Found incompatible Python interpreter (3.7.3) and Python libraries ()

I'll mess with it a bit I guess.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

In D64812#1588040 , @JDevlieghere 
wrote:

> If that works in `3.4` I'm happy to go that way!


FWICS it's been added in 3.12, so no.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [lldb] r366247 - Fix LLDB Windows build Python version logic after r366243

2019-07-16 Thread Reid Kleckner via lldb-commits

Author: rnk
Date: Tue Jul 16 11:46:51 2019
New Revision: 366247

URL: http://llvm.org/viewvc/llvm-project?rev=366247&view=rev
Log:
Fix LLDB Windows build Python version logic after r366243

Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=366247&r1=366246&r2=366247&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Tue Jul 16 11:46:51 2019
@@ -139,6 +139,7 @@ function(find_python_libs_windows)
  PYTHONLIBS_VERSION_STRING "${python_version_str}")
 message(STATUS "Found Python version ${PYTHONLIBS_VERSION_STRING}")
 string(REGEX REPLACE "([0-9]+)[.]([0-9]+)[.][0-9]+" "python\\1\\2" 
PYTHONLIBS_BASE_NAME "${PYTHONLIBS_VERSION_STRING}")
+set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
 unset(python_version_str)
   else()
 message(WARNING "Unable to find ${PYTHON_INCLUDE_DIR}/patchlevel.h, Python 
installation is corrupt.")


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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Reid Kleckner via Phabricator via lldb-commits

rnk added a comment.

In D64812#1588055 , @rnk wrote:

> You broke my build. =/ I got this output:
>
>   CMake Error at C:/src/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:201 
> (message):
> Found incompatible Python interpreter (3.7.3) and Python libraries ()
>
>
> I'll mess with it a bit I guess.


Fixed that in r366247. Apparently Windows has totally custom Python version 
detection logic.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: lldb/trunk/cmake/modules/LLDBConfig.cmake:197
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()

As a small optimization, I think you can prepend major+minor version into 
`Python_ADDITIONAL_VERSIONS`. Then it will prefer finding the same libs as 
interpreter.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

Re: [Lldb-commits] [lldb] r361915 - build: only search for the needed python type

2019-07-16 Thread Reid Kleckner via lldb-commits

Doesn't this regress building with the VS generator? Was that already
broken? It seems like this should've been sent to Zach, who added this
logic, for review.

On Tue, May 28, 2019 at 7:23 PM Saleem Abdulrasool via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: compnerd
> Date: Tue May 28 19:26:29 2019
> New Revision: 361915
>
> URL: http://llvm.org/viewvc/llvm-project?rev=361915&view=rev
> Log:
> build: only search for the needed python type
>
> Windows has different types of runtime libraries which are ABI
> incompatible with one another.  This requires that the debug build of
> lldb link against the debug build of python.  Adjust the python search
> to search for only the required type of python.  This permits building a
> release build of lldb against just the release build of python.
>
> Modified:
> lldb/trunk/cmake/modules/LLDBConfig.cmake
>
> Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=361915&r1=361914&r2=361915&view=diff
>
> ==
> --- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
> +++ lldb/trunk/cmake/modules/LLDBConfig.cmake Tue May 28 19:26:29 2019
> @@ -153,83 +153,39 @@ function(find_python_libs_windows)
>endif()
>
>file(TO_CMAKE_PATH "${PYTHON_HOME}" PYTHON_HOME)
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_DEBUG_EXE)
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}_d.lib"
> PYTHON_DEBUG_LIB)
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}_d.dll"
> PYTHON_DEBUG_DLL)
> -
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}.lib"
> PYTHON_RELEASE_LIB)
> -  file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}.dll"
> PYTHON_RELEASE_DLL)
> -
> -  if (NOT EXISTS ${PYTHON_DEBUG_EXE})
> -message("Unable to find ${PYTHON_DEBUG_EXE}")
> -unset(PYTHON_DEBUG_EXE)
> -  endif()
> -
> -  if (NOT EXISTS ${PYTHON_RELEASE_EXE})
> -message("Unable to find ${PYTHON_RELEASE_EXE}")
> -unset(PYTHON_RELEASE_EXE)
> -  endif()
> -
> -  if (NOT EXISTS ${PYTHON_DEBUG_LIB})
> -message("Unable to find ${PYTHON_DEBUG_LIB}")
> -unset(PYTHON_DEBUG_LIB)
> -  endif()
> -
> -  if (NOT EXISTS ${PYTHON_RELEASE_LIB})
> -message("Unable to find ${PYTHON_RELEASE_LIB}")
> -unset(PYTHON_RELEASE_LIB)
> -  endif()
> -
> -  if (NOT EXISTS ${PYTHON_DEBUG_DLL})
> -message("Unable to find ${PYTHON_DEBUG_DLL}")
> -unset(PYTHON_DEBUG_DLL)
> -  endif()
> +  # TODO(compnerd) when CMake Policy `CMP0091` is set to NEW, we should
> use
> +  # if(CMAKE_MSVC_RUNTIME_LIBRARY MATCHES MultiThreadedDebug)
> +  if(CMAKE_BUILD_TYPE STREQUAL Debug)
> +file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_EXE)
> +file(TO_CMAKE_PATH
> "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}_d.lib" PYTHON_LIB)
> +file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}_d.dll"
> PYTHON_DLL)
> +  else()
> +file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_EXE)
> +file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}.lib"
> PYTHON_LIB)
> +file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}.dll"
> PYTHON_DLL)
> +  endif()
> +
> +  foreach(component PYTHON_EXE;PYTHON_LIB;PYTHON_DLL)
> +if(NOT EXISTS ${${component}})
> +  message("unable to find ${component}")
> +  unset(${component})
> +endif()
> +  endforeach()
>
> -  if (NOT EXISTS ${PYTHON_RELEASE_DLL})
> -message("Unable to find ${PYTHON_RELEASE_DLL}")
> -unset(PYTHON_RELEASE_DLL)
> -  endif()
> -
> -  if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB
> AND PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
> -message("Python installation is corrupt. Python support will be
> disabled for this build.")
> +  if (NOT PYTHON_EXE OR NOT PYTHON_LIB OR NOT PYTHON_DLL)
> +message("Unable to find all Python components.  Python support will
> be disabled for this build.")
>  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
>  return()
>endif()
>
> -  # Generator expressions are evaluated in the context of each build
> configuration generated
> -  # by CMake. Here we use the $:VALUE logical generator
> expression to ensure
> -  # that the debug Python library, DLL, and executable are used in the
> Debug build configuration.
> -  #
> -  # Generator expressions can be difficult to grok at first so here's a
> breakdown of the one
> -  # used for PYTHON_LIBRARY:
> -  #
> -  # 1. $ evaluates to 1 when the Debug configuration is
> being generated,
> -  #or 0 in all other cases.
> -  # 2. $<$:${PYTHON_DEBUG_LIB}> expands to
> ${PYTHON_DEBUG_LIB} when the Debug
> -  #configuration is being generated, or nothing (literally) in all
> other cases.
> -  # 3. $<$>:${PYTHON_RELEASE_LIB}> expands to
> ${PYTHON_RELEASE_LIB} when
> -  #

[Lldb-commits] [lldb] r366261 - [Symbol] Remove unused fields from ClangASTContext

2019-07-16 Thread Alex Langford via lldb-commits

Author: xiaobai
Date: Tue Jul 16 14:05:08 2019
New Revision: 366261

URL: http://llvm.org/viewvc/llvm-project?rev=366261&view=rev
Log:
[Symbol] Remove unused fields from ClangASTContext

Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h

Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=366261&r1=366260&r2=366261&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Tue Jul 16 14:05:08 2019
@@ -982,7 +982,6 @@ protected:
 std::unique_ptr  m_ast_up;
 std::unique_ptr m_language_options_up;
 std::unique_ptr m_file_manager_up;
-std::unique_ptr   m_file_system_options_up;
 std::unique_ptr   m_source_manager_up;
 std::unique_ptr   m_diagnostics_engine_up;
 std::unique_ptr  m_diagnostic_consumer_up;
@@ -1001,7 +1000,6 @@ protected:
 clang::ExternalASTMerger::OriginMap m_origins;
 uint32_tm_pointer_byte_size;
 boolm_ast_owned;
-boolm_can_evaluate_expressions;
 /// The sema associated that is currently used to build this ASTContext.
 /// May be null if we are already done parsing this ASTContext or the
 /// ASTContext wasn't created by parsing source code.


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

[Lldb-commits] [PATCH] D63667: Support __kernel_rt_sigreturn in frame initialization

2019-07-16 Thread Jason Molenda via Phabricator via lldb-commits

jasonmolenda accepted this revision.
jasonmolenda added a comment.
This revision is now accepted and ready to land.

Sorry yes, I should have marked this as approved.  I don't have a linux machine 
handy so I haven't looked into the problem Jan reports with the change -- fwiw 
if you turn on unwind logging ('log enable lldb unwind' before you backtrace at 
a stop), it will tell you which unwind rule it is using to find the caller's 
return pc value as it goes up the stack.  It's a little tricky to read at 
first, but once you get the hang of it you can usually spot the problem quickly 
and understand why lldb is behaving the way it is.  But just looking at the 
source changes you're making, I'm fine with this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63667/new/

https://reviews.llvm.org/D63667



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

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added a reviewer: sgraenitz.
Herald added a subscriber: mgorny.
Herald added a project: LLDB.

I'm pretty sure there's no need to have this logic living in LLDBStandalone. We 
always go through `LLDBConfig.cmake` which has the canonical way to find the 
Python libs and interpreter.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64821

Files:
  lldb/cmake/modules/LLDBStandalone.cmake


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -87,18 +87,6 @@
   include(CheckAtomic)
   include(LLVMDistributionSupport)
 
-  set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 2.7)
-  if (PYTHON_EXECUTABLE STREQUAL "")
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-  "Unable to find Python interpreter, required for builds and 
testing.
-   Please install Python or specify the PYTHON_EXECUTABLE CMake 
variable.")
-endif()
-  else()
-message(STATUS "Found PythonInterp: ${PYTHON_EXECUTABLE}")
-  endif()
-
   set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
   set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
 


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -87,18 +87,6 @@
   include(CheckAtomic)
   include(LLVMDistributionSupport)
 
-  set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 2.7)
-  if (PYTHON_EXECUTABLE STREQUAL "")
-include(FindPythonInterp)
-if( NOT PYTHONINTERP_FOUND )
-  message(FATAL_ERROR
-  "Unable to find Python interpreter, required for builds and testing.
-   Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
-endif()
-  else()
-message(STATUS "Found PythonInterp: ${PYTHON_EXECUTABLE}")
-  endif()
-
   set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
   set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64823: [CMake] Default LLDB_PATH_TO_LLVM_BUILD to LLVM_DIR

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: sgraenitz, mgorny, xiaobai.
Herald added a subscriber: abidh.
Herald added a project: LLDB.

When doing a standalone build, without setting `LLDB_PATH_TO_LLVM_BUILD` or 
`LLDB_PATH_TO_CLANG_BUILD`, you get the following error.

  CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package):
Could not find a package configuration file provided by "LLVM" with any of
the following names:
  
  LLVMConfig.cmake
  llvm-config.cmake
  
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.

This suggests setting `LLVM_DIR` to LLVM's install directory. However, 
LLDBStandalone.cmake takes `LLDB_PATH_TO_LLVM_BUILD` as its hint. As someone 
who isn't familiar with the standalone process, this is rather confusing. I 
assume there's good reason to use a separate variable here, so I didn't want to 
change that. Instead, I propose using `LLVM_DIR` as the default for 
`LLDB_PATH_TO_LLVM_BUILD`. That way, passing `-DLLVM_DIR=/path/to/llvm` is 
sufficient to get the standalone build working.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64823

Files:
  lldb/cmake/modules/LLDBStandalone.cmake


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -14,7 +14,7 @@
 
   option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-  set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
+  set(LLDB_PATH_TO_LLVM_BUILD "${LLVM_DIR}" CACHE PATH "Path to LLVM build 
tree")
   set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path 
to Clang build tree")
 
   file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -14,7 +14,7 @@
 
   option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
-  set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
+  set(LLDB_PATH_TO_LLVM_BUILD "${LLVM_DIR}" CACHE PATH "Path to LLVM build tree")
   set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
 
   file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere marked an inline comment as done.
JDevlieghere added inline comments.



Comment at: lldb/trunk/cmake/modules/LLDBConfig.cmake:197
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()

mgorny wrote:
> As a small optimization, I think you can prepend major+minor version into 
> `Python_ADDITIONAL_VERSIONS`. Then it will prefer finding the same libs as 
> interpreter.
The implementation of `PythonLibs` should already honor the minor/major version 
it gets from the interpreter: 
https://github.com/Kitware/CMake/blob/master/Modules/FindPythonLibs.cmake#L116


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64824: [CMake] Move standalone check so we don't have to reconfigure LLDB

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: sgraenitz, mgorny, xiaobai.
Herald added subscribers: teemperor, jfb.
Herald added a project: LLDB.

By moving the standalone check into the main CMake file, the whole file is 
ignored in a regular (non-standalone) build. This means that you can make 
changes to LLDBStandalone.cmake without having to reconfigure a build in a 
different directory. This matters when you share one source repository with 
different build directories (e.g. release-assert, debug, standalone).


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64824

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake

Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,3 +1,30 @@
+project(lldb)
+
+option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
+
+set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
+set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
+
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
+
+find_package(LLVM REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+
+# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
+set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+
+set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
+set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
+set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
+
+set(lit_file_name "llvm-lit")
+if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+  set(lit_file_name "${lit_file_name}.py")
+endif()
+
 function(append_configuration_directories input_dir output_dirs)
   set(dirs_list ${input_dir})
   foreach(config_type ${LLVM_CONFIGURATION_TYPES})
@@ -7,118 +34,88 @@
   set(${output_dirs} ${dirs_list} PARENT_SCOPE)
 endfunction()
 
-# If we are not building as a part of LLVM, build LLDB as an
-# standalone project, using LLVM as an external library:
-if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
-  project(lldb)
-
-  option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
-
-  set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-  set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
-
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-  find_package(LLVM REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-  find_package(Clang REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
 
-  # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
-  set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs)
+find_program(lit_full_path ${lit_file_name} ${config_dirs} NO_DEFAULT_PATH)
+set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
-  set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
-  set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
-  set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
-
-  set(lit_file_name "llvm-lit")
-  if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
-set(lit_file_name "${lit_file_name}.py")
+if(CMAKE_CROSSCOMPILING)
+  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
+message(FATAL_ERROR
+  "Attempting to cross-compile LLDB standalone but no native LLVM build
+  found. Please cross-compile LLVM as well.")
   endif()
 
-  append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs)
-  find_program(lit_full_path ${lit_file_name} ${config_dirs} NO_DEFAULT_PATH)
-  set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
-
-  if(CMAKE_CROSSCOMPILING)
-set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
-if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
-  message(FATAL_ERROR
-"Attempting to cross-compile LLDB standalone but no native LLVM build
-found. Please cross-compile LLVM as well.")
-endif()
-
-if (CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
-  set(HOST_EXECUTABLE_SUFFIX ".exe")
-endif()
-
-if (NOT CMAKE_CONFIGURATION_TYPES)
-  set(LLVM_TABLEGEN_EXE
-"${LLVM_NATIVE_BUILD}/bi

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-16 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

Actually, right now I'm trying to figure out where the interpreter is found 
because cmake is finding different, incompatible versions of the interpreter 
(2.7) and the libs (3.6).

On Windows, it looks like LLDBConfig.cmake doesn't explicitly look for the 
interpreter, only the libs.  By the time find_python_libs_windows runs, the 
interpreter is already set to the wrong version.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64821/new/

https://reviews.llvm.org/D64821



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

[Lldb-commits] [PATCH] D64824: [CMake] Move standalone check so we don't have to reconfigure LLDB

2019-07-16 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added inline comments.



Comment at: lldb/CMakeLists.txt:14
 
-include(LLDBStandalone)
+# If we are not building as a part of LLVM, build LLDB as an
+# standalone project, using LLVM as an external library:

Nit:  s/an/a/


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64824/new/

https://reviews.llvm.org/D64824



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

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

In D64812#1588061 , @rnk wrote:

> In D64812#1588055 , @rnk wrote:
>
> > You broke my build. =/ I got this output:
> >
> >   CMake Error at 
> > C:/src/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:201 (message):
> > Found incompatible Python interpreter (3.7.3) and Python libraries ()
> >
> >
> > I'll mess with it a bit I guess.
>
>
> Fixed that in r366247. Apparently Windows has totally custom Python version 
> detection logic.


Still busted for me, even with rnk's fix:

- LLDB Found PythonExecutable: C:/Python36/python_d.exe
- LLDB Found PythonLibs: C:/Python36/libs/python36_d.lib
- LLDB Found PythonDLL: C:/Python36/python36_d.dll
- LLDB Found PythonIncludeDirs: C:/Python36/Include CMake Error at 
D:/src/llvm/mono/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:204 
(message): Found incompatible Python interpreter (2.7.15) and Python libraries 
(3.6.8)

Note that it found all the Python things, but somehow the Python interpreter is 
still set incorrectly.  I haven't been able to find where PYTHON_VERSION_STRING 
gets set, but it seems to happen long before the Windows-specific detection 
logic and it seems to ignore the PYTHON_HOME setting.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-16 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik updated this revision to Diff 210127.
shafik added a comment.

Applying clang-format to test


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64777/new/

https://reviews.llvm.org/D64777

Files:
  
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
  
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
  
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
  source/Symbol/ClangASTContext.cpp


Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -1615,10 +1615,11 @@
 void ClangASTContext::CreateFunctionTemplateSpecializationInfo(
 FunctionDecl *func_decl, clang::FunctionTemplateDecl *func_tmpl_decl,
 const TemplateParameterInfos &infos) {
-  TemplateArgumentList template_args(TemplateArgumentList::OnStack, 
infos.args);
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 
-  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl, &template_args,
-   nullptr);
+  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl,
+   template_args_ptr, nullptr);
 }
 
 ClassTemplateDecl *ClangASTContext::CreateClassTemplateDecl(
Index: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
@@ -0,0 +1,17 @@
+template  struct M {};
+
+template  void f(T &t);
+
+template <> void f(int &t) {
+  typedef M VType;
+
+  VType p0; // break here
+}
+
+int main() {
+  int x;
+
+  f(x);
+
+  return 0;
+}
Index: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
@@ -0,0 +1,17 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestFunctionTemplateSpecializationTempArgs(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_function_template_specialization_temp_args(self):
+self.build()
+
+(self.target, self.process, _, bkpt) = 
lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+self.expect("expr p0",
+substrs=['(VType) $0 = {}'])
Index: 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules


Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -1615,10 +1615,11 @@
 void ClangASTContext::CreateFunctionTemplateSpecializationInfo(
 FunctionDecl *func_decl, clang::FunctionTemplateDecl *func_tmpl_decl,
 const TemplateParameterInfos &infos) {
-  TemplateArgumentList template_args(TemplateArgumentList::OnStack, infos.args);
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 
-  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl, &template_args,
-   nullptr);
+  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl,
+   template_args_ptr, nullptr);
 }
 
 ClassTemplateDecl *ClangASTContext::CreateClassTemplateDecl(
Index: packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
@@ -0,0 +1,17 @@
+template  struct M {};
+
+template  void f(T &t);
+
+template <> void f(int &t) {
+  typedef M VType;
+
+  VType p0; // break here
+}
+
+int main() {
+  int x;
+
+  f(x);
+
+  return 0;
+}
Index: packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializatio

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

OK, the only way I was able to make this work was to remove all traces of 
Python 2.x from my machine.  As long as the older Python existed on my machine 
CMake would find that one, regardless of which one was in my PATH or indicated 
by PYTHON_HOME_DIR.  Of course, it required killing the cmake cache a couple 
times, too.

Interestingly, this suggests that I've been in this allegedly "incompatible" 
state for a while (Python 2.7 interpreter with Python 3.6 for everything else), 
and there were no obvious errors.  I was able to build and test lldb, including 
all the Python-based tests.  This makes me think this FATAL_ERROR message might 
not actually be necessary.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D62570: Use LLVM's debug line parser in LLDB

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere updated this revision to Diff 210222.
JDevlieghere marked 3 inline comments as done.
JDevlieghere retitled this revision from "[WIP] Use LLVM's debug line parser in 
LLDB" to "Use LLVM's debug line parser in LLDB".
JDevlieghere added a comment.

- Address code review feedback
- Fix support files for type units


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62570/new/

https://reviews.llvm.org/D62570

Files:
  lldb/include/lldb/Core/FileSpecList.h
  lldb/include/lldb/Symbol/CompileUnit.h
  lldb/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugLine.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugLine.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Symbol/CompileUnit.cpp

Index: lldb/source/Symbol/CompileUnit.cpp
===
--- lldb/source/Symbol/CompileUnit.cpp
+++ lldb/source/Symbol/CompileUnit.cpp
@@ -202,6 +202,10 @@
   m_line_table_up.reset(line_table);
 }
 
+void CompileUnit::SetSupportFiles(const FileSpecList &support_files) {
+  m_support_files = support_files;
+}
+
 DebugMacros *CompileUnit::GetDebugMacros() {
   if (m_debug_macros_sp.get() == nullptr) {
 if (m_flags.IsClear(flagsParsedDebugMacros)) {
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -58,7 +58,6 @@
 #include "DWARFDebugAbbrev.h"
 #include "DWARFDebugAranges.h"
 #include "DWARFDebugInfo.h"
-#include "DWARFDebugLine.h"
 #include "DWARFDebugMacro.h"
 #include "DWARFDebugRanges.h"
 #include "DWARFDeclContext.h"
@@ -72,6 +71,7 @@
 #include "SymbolFileDWARFDwo.h"
 #include "SymbolFileDWARFDwp.h"
 
+#include "llvm/DebugInfo/DWARF/DWARFContext.h"
 #include "llvm/Support/FileSystem.h"
 
 #include 
@@ -161,6 +161,57 @@
 
 } // anonymous namespace end
 
+static const llvm::DWARFDebugLine::LineTable *
+ParseLLVMLineTable(lldb_private::DWARFContext &context,
+   llvm::DWARFDebugLine &line, dw_offset_t line_offset,
+   dw_offset_t unit_offset) {
+  Log *log = LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_INFO);
+
+  llvm::DWARFDataExtractor data = context.getOrLoadLineData().GetAsLLVM();
+  llvm::DWARFContext &ctx = context.GetAsLLVM();
+  llvm::Expected line_table =
+  line.getOrParseLineTable(
+  data, line_offset, ctx, nullptr, [&](llvm::Error e) {
+LLDB_LOG_ERROR(log, std::move(e),
+   "SymbolFileDWARF::ParseLineTable failed to parse");
+  });
+
+  if (!line_table) {
+LLDB_LOG_ERROR(log, line_table.takeError(),
+   "SymbolFileDWARF::ParseLineTable failed to parse");
+return nullptr;
+  }
+  return *line_table;
+}
+
+static void
+ParseSupportFilesFromPrologue(const lldb::ModuleSP &module,
+  const llvm::DWARFDebugLine::Prologue &prologue,
+  llvm::StringRef compile_dir,
+  FileSpecList &support_files) {
+  support_files.Append({});
+
+  const size_t number_of_files = prologue.FileNames.size();
+  for (size_t idx = 1; idx <= number_of_files; ++idx) {
+std::string original_file;
+if (!prologue.getFileNameByIndex(
+idx, compile_dir,
+llvm::DILineInfoSpecifier::FileLineInfoKind::Default,
+original_file))
+  continue;
+
+std::string remapped_file;
+if (!prologue.getFileNameByIndex(
+idx, compile_dir,
+llvm::DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath,
+remapped_file))
+  continue;
+
+module->RemapSourceFile(llvm::StringRef(original_file), remapped_file);
+support_files.Append(FileSpec(remapped_file));
+  }
+}
+
 FileSpecList SymbolFileDWARF::GetSymlinkPaths() {
   return GetGlobalPluginProperties()->GetSymLinkPaths();
 }
@@ -792,19 +843,9 @@
 
 bool SymbolFileDWARF::ParseSupportFiles(CompileUnit &comp_unit,
 FileSpecList &support_files) {
-  ASSERT_MODULE_LOCK(this);
-  if (DWARFUnit *unit = GetDWARFCompileUnit(&comp_unit)) {
-const dw_offset_t stmt_list = unit->GetLineTableOffset();
-if (stmt_list != DW_INVALID_OFFSET) {
-  // All file indexes in DWARF are one based and a file of index zero is
-  // supposed to be the compile unit itself.
-  support_files.Append(comp_unit);
-  return DWARFDebugLine::ParseSupportFiles(comp_unit.GetModule(),
-   m_context.getOrLoadLineData(),
-   stmt_list, support_files, unit);
-}
-  }
-  return false;
+  if (!comp_unit.GetLineTable())
+ParseLineTable(comp_unit);
+  return true;
 }
 
 FileSpec SymbolFileDWARF::GetFile(DWARFUnit &unit, size_t file_idx) {
@@ -833,10 +874,19 @@
   auto iter_bool

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D64821#1588424 , @amccarth wrote:

> Actually, right now I'm trying to figure out where the interpreter is found 
> because cmake is finding different, incompatible versions of the interpreter 
> (2.7) and the libs (3.6).
>
> On Windows, it looks like LLDBConfig.cmake doesn't explicitly look for the 
> interpreter, only the libs.  By the time find_python_libs_windows runs, the 
> interpreter is already set to the wrong version.


For an in-tree build I assume it would be LLVM setting the interpreter. Maybe 
we should we unset the variables here so we can start clean?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64821/new/

https://reviews.llvm.org/D64821



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

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Indeed, the culprit appears to be 
https://github.com/llvm/llvm-project/blob/master/llvm/CMakeLists.txt#L645, 
which prefer Python 3 over Python 2.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64821/new/

https://reviews.llvm.org/D64821



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

[Lldb-commits] [PATCH] D62570: Use LLVM's debug line parser in LLDB

2019-07-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

So in the actual line table parsing code it seems like we are creating a line 
table in LLVM format, complete with sequences and a bunch of LLVM data 
structures, and then copying the results over into LLDB and then throwing away 
the LLVM line table. It would be nicer to modify the LLVM line table code to be 
able to get a callback when a row was pushed (if it isn't already in that 
format) and expose that so clients, like LLDB, can just get a callback and only 
store the data structure we care about. This would allow us to share the llvm 
line table parsing code and re-use it in LLDB, but not require twice the memory 
and overhead. Symbolication tools could also take advantage of this by not 
storing any rows except the closest matching row.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:201
+original_file))
+  continue;
+

I am worried about this continue stuff. If this fails, all of our file indexes 
will be off and nothing will make sense. We need the indexes in the support 
files to match those in the prologue.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:208
+remapped_file))
+  continue;
+

Ditto



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:211
+module->RemapSourceFile(llvm::StringRef(original_file), remapped_file);
+support_files.Append(FileSpec(remapped_file));
+  }

Is this FileSpec constructor going to do the right thing for all path types 
(windows, linux, etc)?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62570/new/

https://reviews.llvm.org/D62570



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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-16 Thread Alex Langford via Phabricator via lldb-commits

xiaobai created this revision.
xiaobai added reviewers: teemperor, shafik, jingham, JDevlieghere, aprantl.
Herald added subscribers: arphaman, emaste.

Target doesn't really need to know about ClangASTContext more than any
other TypeSystem. We can create a method ClangASTContext::GetScratch for
anything who needs a ClangASTContext specifically instead of just a
generic TypeSystem.


https://reviews.llvm.org/D64844

Files:
  include/lldb/Symbol/ClangASTContext.h
  include/lldb/Target/Target.h
  source/API/SBTarget.cpp
  source/Breakpoint/Watchpoint.cpp
  source/Core/DumpDataExtractor.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
  source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
  source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  source/Plugins/Language/CPlusPlus/LibCxx.cpp
  source/Plugins/Language/ObjC/NSArray.cpp
  source/Plugins/Language/ObjC/NSDictionary.cpp
  source/Plugins/Language/ObjC/NSError.cpp
  source/Plugins/Language/ObjC/NSException.cpp
  source/Plugins/Language/ObjC/NSIndexPath.cpp
  source/Plugins/Language/ObjC/NSString.cpp
  
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
  source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  source/Symbol/ClangASTContext.cpp
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2293,15 +2293,6 @@
   return utility_fn;
 }
 
-ClangASTContext *Target::GetScratchClangASTContext(bool create_on_demand) {
-  if (m_valid) {
-if (TypeSystem *type_system = GetScratchTypeSystemForLanguage(
-nullptr, eLanguageTypeC, create_on_demand))
-  return llvm::dyn_cast(type_system);
-  }
-  return nullptr;
-}
-
 ClangASTImporterSP Target::GetClangASTImporter() {
   if (m_valid) {
 if (!m_ast_importer_sp) {
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -331,6 +331,13 @@
   return *g_map_ptr;
 }
 
+ClangASTContext *ClangASTContext::GetScratch(Target &target,
+ bool create_on_demand) {
+  return llvm::cast_or_null(
+  target.GetScratchTypeSystemForLanguage(nullptr, eLanguageTypeC,
+ create_on_demand));
+}
+
 bool ClangASTContext::IsOperator(const char *name,
  clang::OverloadedOperatorKind &op_kind) {
   if (name == nullptr || name[0] == '\0')
Index: source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -411,8 +411,7 @@
 }
 #endif
 
-ClangASTContext *ast_ctx =
-m_process->GetTarget().GetScratchClangASTContext();
+auto *ast_ctx = ClangASTContext::GetScratch(m_process->GetTarget());
 if (ast_ctx->getASTContext() &&
 m_dispatch_tsd_indexes_addr != LLDB_INVALID_ADDRESS) {
   CompilerType uint16 =
Index: source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
===
--- source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -186,8 +186,8 @@
 
   // Also make the FunctionCaller for this UtilityFunction:
 
-  ClangASTContext *clang_ast_context =
-  thread.GetProcess()->GetTarget().GetScratchClangASTContext();
+  auto *clang_ast_context =
+  ClangASTContext::GetScratch(thread.GetProcess()->GetTarget());
   CompilerType get_thread_item_info_return_type =
   clang_ast_context->GetBasicType(eBasicTypeVoid).GetPointerType();
 
@@ -238,7 +238,7 @@
   lldb::StackFrameSP thread_cur_frame = thread.GetStackFrameAtIndex(0);
   ProcessSP process_sp(thread.CalculateProcess());
   TargetSP target_sp(thread.CalculateTarget());
-  ClangASTContex

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-16 Thread Alex Langford via Phabricator via lldb-commits

xiaobai updated this revision to Diff 210229.
xiaobai added a comment.

Remove ClangASTContext header from Target.cpp


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64844/new/

https://reviews.llvm.org/D64844

Files:
  include/lldb/Symbol/ClangASTContext.h
  include/lldb/Target/Target.h
  source/API/SBTarget.cpp
  source/Breakpoint/Watchpoint.cpp
  source/Core/DumpDataExtractor.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
  source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
  source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  source/Plugins/Language/CPlusPlus/LibCxx.cpp
  source/Plugins/Language/ObjC/NSArray.cpp
  source/Plugins/Language/ObjC/NSDictionary.cpp
  source/Plugins/Language/ObjC/NSError.cpp
  source/Plugins/Language/ObjC/NSException.cpp
  source/Plugins/Language/ObjC/NSIndexPath.cpp
  source/Plugins/Language/ObjC/NSString.cpp
  
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
  source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  source/Symbol/ClangASTContext.cpp
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -27,6 +27,7 @@
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/StructuredDataImpl.h"
 #include "lldb/Core/ValueObject.h"
+#include "lldb/Expression/ExpressionVariable.h"
 #include "lldb/Expression/REPL.h"
 #include "lldb/Expression/UserExpression.h"
 #include "lldb/Host/Host.h"
@@ -36,7 +37,6 @@
 #include "lldb/Interpreter/OptionGroupWatchpoint.h"
 #include "lldb/Interpreter/OptionValues.h"
 #include "lldb/Interpreter/Property.h"
-#include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Symbol/ClangASTImporter.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/ObjectFile.h"
@@ -2293,15 +2293,6 @@
   return utility_fn;
 }
 
-ClangASTContext *Target::GetScratchClangASTContext(bool create_on_demand) {
-  if (m_valid) {
-if (TypeSystem *type_system = GetScratchTypeSystemForLanguage(
-nullptr, eLanguageTypeC, create_on_demand))
-  return llvm::dyn_cast(type_system);
-  }
-  return nullptr;
-}
-
 ClangASTImporterSP Target::GetClangASTImporter() {
   if (m_valid) {
 if (!m_ast_importer_sp) {
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -331,6 +331,13 @@
   return *g_map_ptr;
 }
 
+ClangASTContext *ClangASTContext::GetScratch(Target &target,
+ bool create_on_demand) {
+  return llvm::cast_or_null(
+  target.GetScratchTypeSystemForLanguage(nullptr, eLanguageTypeC,
+ create_on_demand));
+}
+
 bool ClangASTContext::IsOperator(const char *name,
  clang::OverloadedOperatorKind &op_kind) {
   if (name == nullptr || name[0] == '\0')
Index: source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -411,8 +411,7 @@
 }
 #endif
 
-ClangASTContext *ast_ctx =
-m_process->GetTarget().GetScratchClangASTContext();
+auto *ast_ctx = ClangASTContext::GetScratch(m_process->GetTarget());
 if (ast_ctx->getASTContext() &&
 m_dispatch_tsd_indexes_addr != LLDB_INVALID_ADDRESS) {
   CompilerType uint16 =
Index: source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
===
--- source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -186,8 +186,8 @@
 
   // Also make the FunctionCaller for this UtilityFunction:
 
-  ClangASTContext *clang_ast_context =
-  thread.GetProcess()->GetTarget().GetScratchClangASTContext();
+  auto *clang_ast_context =
+  ClangA

[Lldb-commits] [PATCH] D64812: [CMake] Fail when Python interpreter doesn't match Python libraries version

2019-07-16 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: lldb/trunk/cmake/modules/LLDBConfig.cmake:197
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()

JDevlieghere wrote:
> mgorny wrote:
> > As a small optimization, I think you can prepend major+minor version into 
> > `Python_ADDITIONAL_VERSIONS`. Then it will prefer finding the same libs as 
> > interpreter.
> The implementation of `PythonLibs` should already honor the minor/major 
> version it gets from the interpreter: 
> https://github.com/Kitware/CMake/blob/master/Modules/FindPythonLibs.cmake#L116
But note that it is appended *after* `Python_ADDITIONAL_VERSIONS`, so in our 
case full version list takes precedence over that. If I explicitly set 
`PYTHON_EXECUTABLE` to 2.7, it will still prefer libs from 3.x.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64812/new/

https://reviews.llvm.org/D64812



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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-16 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor accepted this revision.
teemperor added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64844/new/

https://reviews.llvm.org/D64844



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

56 matches

Mail list logo