[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 410920.
d-millar added a comment.

Rebased on v14


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/CMakeLists.txt
  lldb/bindings/CMakeLists.txt
  lldb/bindings/java/CMakeLists.txt
  lldb/bindings/java/SWIG/LldbScriptInterpreter.java
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java-wrapper.swig
  lldb/bindings/java/java.swig
  lldb/cmake/modules/FindJavaAndSwig.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/docs/resources/build.rst
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/API/CMakeLists.txt
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/liblldb-private.exports
  lldb/source/API/liblldb.exports
  lldb/source/Commands/CommandObjectBreakpointCommand.cpp
  lldb/source/Commands/CommandObjectScript.cpp
  lldb/source/Commands/CommandObjectWatchpointCommand.cpp
  lldb/source/Interpreter/OptionArgParser.cpp
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/Java.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/Java.h
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.h
  lldb/test/CMakeLists.txt
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/independent_state.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions_2.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/testmodule.java
  lldb/test/Shell/ScriptInterpreter/Java/bindings.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_function_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_oneline_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/command_script_import.test
  lldb/test/Shell/ScriptInterpreter/Java/convenience_variables.test
  lldb/test/Shell/ScriptInterpreter/Java/fail_breakpoint_oneline.test
  lldb/test/Shell/ScriptInterpreter/Java/independent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/io.test
  lldb/test/Shell/ScriptInterpreter/Java/java-python.test
  lldb/test/Shell/ScriptInterpreter/Java/java.test
  lldb/test/Shell/ScriptInterpreter/Java/lit.local.cfg
  lldb/test/Shell/ScriptInterpreter/Java/nested_sessions.test
  lldb/test/Shell/ScriptInterpreter/Java/partial_statements.test
  lldb/test/Shell/ScriptInterpreter/Java/persistent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/print.test
  lldb/test/Shell/ScriptInterpreter/Java/quit.test
  lldb/test/Shell/ScriptInterpreter/Java/watchpoint_callback.test
  lldb/test/Shell/lit.cfg.py
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.cfg.py
  lldb/unittests/ScriptInterpreter/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/JavaTests.cpp
  lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp

Index: lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
===
--- /dev/null
+++ lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
@@ -0,0 +1,59 @@
+//===-- JavaTests.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Utility/Reproducer.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+namespace {
+class ScriptInterpreterTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+
+// Pretend Linux is the host platform.
+platform_linux::PlatformLinux::Initialize();
+ArchSpec arch("powerpc64-pc-linux");
+Platform::SetHostPlatform(
+platform_linux::PlatformLinux::CreateInstance(true, &arch));
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+} // namespace
+
+TEST_F(ScriptInterpreterTest, Execut

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 389021.
d-millar added a comment.

minor fixes re unnecessary requirement and ConstString->StringRef


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/CMakeLists.txt
  lldb/bindings/CMakeLists.txt
  lldb/bindings/java/CMakeLists.txt
  lldb/bindings/java/SWIG/LldbScriptInterpreter.java
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java-wrapper.swig
  lldb/bindings/java/java.swig
  lldb/cmake/modules/FindJavaAndSwig.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/docs/resources/build.rst
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/API/CMakeLists.txt
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/liblldb-private.exports
  lldb/source/API/liblldb.exports
  lldb/source/Commands/CommandObjectBreakpointCommand.cpp
  lldb/source/Commands/CommandObjectScript.cpp
  lldb/source/Commands/CommandObjectWatchpointCommand.cpp
  lldb/source/Interpreter/OptionArgParser.cpp
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/Java.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/Java.h
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.h
  lldb/test/CMakeLists.txt
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/independent_state.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions_2.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/testmodule.java
  lldb/test/Shell/ScriptInterpreter/Java/bindings.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_function_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_oneline_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/command_script_import.test
  lldb/test/Shell/ScriptInterpreter/Java/convenience_variables.test
  lldb/test/Shell/ScriptInterpreter/Java/fail_breakpoint_oneline.test
  lldb/test/Shell/ScriptInterpreter/Java/independent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/io.test
  lldb/test/Shell/ScriptInterpreter/Java/java-python.test
  lldb/test/Shell/ScriptInterpreter/Java/java.test
  lldb/test/Shell/ScriptInterpreter/Java/lit.local.cfg
  lldb/test/Shell/ScriptInterpreter/Java/nested_sessions.test
  lldb/test/Shell/ScriptInterpreter/Java/partial_statements.test
  lldb/test/Shell/ScriptInterpreter/Java/persistent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/print.test
  lldb/test/Shell/ScriptInterpreter/Java/quit.test
  lldb/test/Shell/ScriptInterpreter/Java/watchpoint_callback.test
  lldb/test/Shell/lit.cfg.py
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.cfg.py
  lldb/unittests/ScriptInterpreter/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/JavaTests.cpp
  lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp

Index: lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
===
--- /dev/null
+++ lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
@@ -0,0 +1,59 @@
+//===-- JavaTests.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Utility/Reproducer.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+namespace {
+class ScriptInterpreterTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+
+// Pretend Linux is the host platform.
+platform_linux::PlatformLinux::Initialize();
+ArchSpec arch("powerpc64-pc-linux");
+Platform::SetHostPlatform(
+platform_linux::PlatformLinux::CreateInstance(true, &arch));
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+} /

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

Am sorry I can't commit build resources, but am certainly willing to commit 
time to solving test problems.  In a very general sense, I think our project 
(Ghidra) will effectively be a test platform for issues with the Java bindings 
to SWIG.


With regard to the set-up for testing, I have noticed differences in behavior 
between the "ninja check-lldb-xxx" suite-testing environment, the llvm-lit test 
sets, and actual lldb runs / individual tests.  I believe (I should never say 
this out loud, but...) the current code handles these environments correctly.


The Java scripting framework requires the ability to find two things:  the Java 
install (and within it libjvm) and the SWIG.jar built from the JNI wrappers.  
If either LD_LIBRARY_PATH or JAVA_HOME is set in whichever environment is in 
use, the code should be able to find libjvm.  If CLASSPATH includes the 
SWIG.jar or we're running out of build, finding it should be handled.  Libjvm 
is loaded dynamically, so the inclusion of my code "should" have no effect on 
environments without Java installed.


I was thinking I would also spend a couple of days isolating the swig logic in 
case supporting the Java interface becomes untenable for you.  Am hoping I can 
pare it down so that our users could point-and-click at an existing lldb repo, 
without necessarily having to build llvm/lldb.


Best, Dave


From: Raphael Isemann via Phabricator 
Sent: Thursday, November 11, 2021 7:23:11 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: pa...@labath.sk; mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

teemperor added a comment.

In D111409#3124194 , @labath wrote:

> In D111409#3124075 , @teemperor 
> wrote:
>
>>> Are you asking for dedicated physical resources for running nightly builds?
>>
>> I don't think any of the current bots have a Java installation so I think 
>> it's either that or we get someone with a bot to setup the required Java 
>> installation.
>
> I don't have a problem with installing the necessary packages on the bot I 
> manage, but I cannot subscribe to tracking down any failures (or flaky 
> tests!) for this configuration (and, in my experience, any new feature like 
> this is going to have flaky tests). Flaky tests (probably just one) are the 
> reason that lua integration is not enabled on this bot.

Sure, I think it should anyway not be up to any bot owner to track down flaky 
tests. And that nested_sessions lua test is anyway randomly failing everywhere 
from what I know.

>> FWIW, if no one wants to host a bot for this then I won't mind testing this 
>> in own CI , but I am not using buildbot so we'll 
>> have to see if that is acceptable for the community (I could also migrate it 
>> to buildbot, but the buildbot interface is just painful to use and I would 
>> prefer not to).
>
> I would rather not proliferate test infrastructures.
>
> I'm not sure which pain points are you referring to, but setting up a 
> buildbot instance is a lot simpler these days than it used to be (in 
> particular, you don't need to track down and install any outdated packages).

It's not the setup, it's just that the lab.llvm.org interface is far less 
usable than Jenkins for tracking down regressions in tests (and Jenkins is 
already not great, so that says something). But that's just my personal 
preference and I agree that lab.llvm.org should be the central place for 
infrastructure.

Anyway, if @labath can run them on his fancy build bot then I would prefer that 
over having it on my bot (because I pay out of my own pocket and CPU cycles are 
$$$).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

In D111409#3124194 , @labath wrote:

> In D111409#3124075 , @teemperor 
> wrote:
>
>>> Are you asking for dedicated physical resources for running nightly builds?
>>
>> I don't think any of the current bots have a Java installation so I think 
>> it's either that or we get someone with a bot to setup the required Java 
>> installation.
>
> I don't have a problem with installing the necessary packages on the bot I 
> manage, but I cannot subscribe to tracking down any failures (or flaky 
> tests!) for this configuration (and, in my experience, any new feature like 
> this is going to have flaky tests). Flaky tests (probably just one) are the 
> reason that lua integration is not enabled on this bot.

Sure, I think it should anyway not be up to any bot owner to track down flaky 
tests. And that nested_sessions lua test is anyway randomly failing everywhere 
from what I know.

>> FWIW, if no one wants to host a bot for this then I won't mind testing this 
>> in own CI , but I am not using buildbot so we'll 
>> have to see if that is acceptable for the community (I could also migrate it 
>> to buildbot, but the buildbot interface is just painful to use and I would 
>> prefer not to).
>
> I would rather not proliferate test infrastructures.
>
> I'm not sure which pain points are you referring to, but setting up a 
> buildbot instance is a lot simpler these days than it used to be (in 
> particular, you don't need to track down and install any outdated packages).

It's not the setup, it's just that the lab.llvm.org interface is far less 
usable than Jenkins for tracking down regressions in tests (and Jenkins is 
already not great, so that says something). But that's just my personal 
preference and I agree that lab.llvm.org should be the central place for 
infrastructure.

Anyway, if @labath can run them on his fancy build bot then I would prefer that 
over having it on my bot (because I pay out of my own pocket and CPU cycles are 
$$$).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D111409#3124075 , @teemperor wrote:

>> Are you asking for dedicated physical resources for running nightly builds?
>
> I don't think any of the current bots have a Java installation so I think 
> it's either that or we get someone with a bot to setup the required Java 
> installation.

I don't have a problem with installing the necessary packages on the bot I 
manage, but I cannot subscribe to tracking down any failures (or flaky tests!) 
for this configuration (and, in my experience, any new feature like this is 
going to have flaky tests). Flaky tests (probably just one) are the reason that 
lua integration is not enabled on this bot.

> FWIW, if no one wants to host a bot for this then I won't mind testing this 
> in own CI , but I am not using buildbot so we'll 
> have to see if that is acceptable for the community (I could also migrate it 
> to buildbot, but the buildbot interface is just painful to use and I would 
> prefer not to).

I would rather not proliferate test infrastructures.

I'm not sure which pain points are you referring to, but setting up a buildbot 
instance is a lot simpler these days than it used to be (in particular, you 
don't need to track down and install any outdated packages).

>> Do you really have a separate build machines for the Python and Lua 
>> scripting environments?
>
> Python is more or less mandatory so all LLDB build bots have that. Lua is 
> tested here: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/
>
> On a more general note: I haven't followed this thread very closely, but I am 
> surprised that this is now adding a Java REPL to LLDB. I think the original 
> "Just add Java bindings" seemed like a reasonable patch but I am not so sure 
> about this. Could we split out the changes for just adding Java bindings to 
> SWIG (which anyway seems like a standalone patch) and then we can talk about 
> the whole Java scripting stuff in a separate review. I don't expect the first 
> one to be controversial so this should also speed things up a bit.

+1


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

> Are you asking for dedicated physical resources for running nightly builds?

I don't think any of the current bots have a Java installation so I think it's 
either that or we get someone with a bot to setup the required Java 
installation.

FWIW, if no one wants to host a bot for this then I won't mind testing this in 
own CI , but I am not using buildbot so we'll have to 
see if that is acceptable for the community (I could also migrate it to 
buildbot, but the buildbot interface is just painful to use and I would prefer 
not to).

> Do you really have a separate build machines for the Python and Lua scripting 
> environments?

Python is more or less mandatory so all LLDB build bots have that. Lua is 
tested here: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/

On a more general note: I haven't followed this thread very closely, but I am 
surprised that this is now adding a Java REPL to LLDB. I think the original 
"Just add Java bindings" seemed like a reasonable patch but I am not so sure 
about this. Could we split out the changes for just adding Java bindings to 
SWIG (which anyway seems like a standalone patch) and then we can talk about 
the whole Java scripting stuff in a separate review. I don't expect the first 
one to be controversial so this should also speed things up a bit.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

Apologies in advance - this may be a repeat message.  Our server went down for 
maintenance mid-send.

So, looking at https://llvm.org/docs/HowToAddABuilder.html, I think I need some 
clarification on your request regarding a build bot.  Are you asking for 
dedicated physical resources for running nightly builds?  That I cannot 
provide.  Our build systems are non-public and firewalled in a way that would 
make them unsuitable for your build process.  (Also, they're government 
resources.)   Do you really have a separate build machines for the Python and 
Lua scripting environments?

Dave



From: David Millar via Phabricator 
Sent: Wednesday, November 10, 2021 3:17:38 PM
To: David Millar; jo...@devlieghere.com
Subject: [PATCH] D111409 : proposed support 
for Java interface to Scripting Bridge

d-millar added a comment.

Hi Jonas,

Apologies for the non-build - I did a fetch/rebase this morning before creating 
the patch.  Do I need to be on a different branch re StringRef vs ConstString?  
(Have seen that discussion in passing but confess I did not follow it in 
detail.)  Any pointers appreciated.

Re testing, I basically duplicated the test set from Lua and ran it using 
"ninja check-lldb-unit" and "ninja check-lldb-shell".  I'm not really 
conversant with your testing infrastructure.  Can you point me to something 
that might be suggest what I'd need to do to generate a bot?  I'll give it a 
shot if I have a starting point.

Also am happy to maintain the code in general and have a few folks in our 
project that can backstop me in case I get run over by a bus or something.  😊

Best,

Dave



From: Jonas Devlieghere via Phabricator 
Sent: Wednesday, November 10, 2021 1:57:51 PM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
teempe...@gmail.com; medismail.benn...@gmail.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409  
https://reviews.llvm.org/D111409: proposed support for Java interface to 
Scripting Bridge

JDevlieghere added a comment.

Hi David, this looks really comprehensive. As far as the code is concerned, it 
has all the parts that we'd want to support another scripting language in LLDB. 
That leaves us with the last remaining questions:

- Testing: having a bot that actually builds & tests this configuration.
- Maintainership: having a commitment from you (or someone else) to maintain 
this code.

Are you willing and able to sign up for those things?

PS: I installed Java and applied your patch on top-of-tree. Things didn't built 
because of the recent change to the plugin manager that now expects 
`StringRef`s instead of `ConstString`s. Please let me know if you've rebased 
the patch and I'd love to give it a try.

Comment at: lldb/cmake/modules/FindJavaAndSwig.cmake:13
+find_package(Java 11.0)
+find_package(JNI REQUIRED)

+if(JAVA_FOUND AND SWIG_FOUND)
--

This can't be `REQUIRED` because that will fail the CMake configuration stage 
when Java isn't found which is not what you want when doing autodetection (the 
default). Making it required is handled at a higher level for `FindJavaAndSwig` 
as a whole.

Repository:

  rLLDB LLDB

CHANGES SINCE LAST ACTION

  https://reviews.llvm.org/D111409/new/

https://reviews.llvm.org/D111409

Repository:

  rLLDB LLDB

CHANGES SINCE LAST ACTION

  https://reviews.llvm.org/D111409/new/

https://reviews.llvm.org/D111409


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

Hi Jonas,


Apologies for the non-build - I did a fetch/rebase this morning before creating 
the patch.  Do I need to be on a different branch re StringRef vs ConstString?  
(Have seen that discussion in passing but confess I did not follow it in 
detail.)  Any pointers appreciated.


Re testing, I basically duplicated the test set from Lua and ran it using 
"ninja check-lldb-unit" and "ninja check-lldb-shell".  I'm not really 
conversant with your testing infrastructure.  Can you point me to something 
that might be suggest what I'd need to do to generate a bot?  I'll give it a 
shot if I have a starting point.


Also am happy to maintain the code in general and have a few folks in our 
project that can backstop me in case I get run over by a bus or something.  😊


Best,

Dave


From: Jonas Devlieghere via Phabricator 
Sent: Wednesday, November 10, 2021 1:57:51 PM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
teempe...@gmail.com; medismail.benn...@gmail.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

JDevlieghere added a comment.

Hi David, this looks really comprehensive. As far as the code is concerned, it 
has all the parts that we'd want to support another scripting language in LLDB. 
That leaves us with the last remaining questions:

- Testing: having a bot that actually builds & tests this configuration.
- Maintainership: having a commitment from you (or someone else) to maintain 
this code.

Are you willing and able to sign up for those things?

PS: I installed Java and applied your patch on top-of-tree. Things didn't built 
because of the recent change to the plugin manager that now expects 
`StringRef`s instead of `ConstString`s. Please let me know if you've rebased 
the patch and I'd love to give it a try.




Comment at: lldb/cmake/modules/FindJavaAndSwig.cmake:13
+find_package(Java 11.0)
+find_package(JNI REQUIRED)
+if(JAVA_FOUND AND SWIG_FOUND)

This can't be `REQUIRED` because that will fail the CMake configuration stage 
when Java isn't found which is not what you want when doing autodetection (the 
default). Making it required is handled at a higher level for `FindJavaAndSwig` 
as a whole.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

Hi David, this looks really comprehensive. As far as the code is concerned, it 
has all the parts that we'd want to support another scripting language in LLDB. 
That leaves us with the last remaining questions:

- Testing: having a bot that actually builds & tests this configuration.
- Maintainership: having a commitment from you (or someone else) to maintain 
this code.

Are you willing and able to sign up for those things?

PS: I installed Java and applied your patch on top-of-tree. Things didn't built 
because of the recent change to the plugin manager that now expects 
`StringRef`s instead of `ConstString`s. Please let me know if you've rebased 
the patch and I'd love to give it a try.




Comment at: lldb/cmake/modules/FindJavaAndSwig.cmake:13
+find_package(Java 11.0)
+find_package(JNI REQUIRED)
+if(JAVA_FOUND AND SWIG_FOUND)

This can't be `REQUIRED` because that will fail the CMake configuration stage 
when Java isn't found which is not what you want when doing autodetection (the 
default). Making it required is handled at a higher level for `FindJavaAndSwig` 
as a whole. 


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 386169.
d-millar added a comment.

OK, well, took my some time but I have made an attempt to address the three 
areas described by Mr. Ingham:

//Support for a scripting language in lldb has three distinct pieces.

1. Making the SB API's available to the scripting languages
2. Adding all the callbacks so the scripting language can be used for 
breakpoint callbacks, data formatters, etc.
3. Adding a REPL for that language to the "script" command

//
With regard to #3, I had hoped JShell would work as a viable REPL.  
Unfortunately, it does not appear to support System.loadLibrary, which makes it 
somewhat useless in the current context.  Because I cannot load the JNI 
libraries, I would not have access to the classes in the Scripting Bridge, 
which sort of defeats the purpose.

As an alternative, I have implemented a quasi-REPL, which allows you to compose 
classes, compile, and run them.  The "script" command behaves for the most part 
like it would for Python or Lua, but have a set of /-prefixed commands, 
described in the initial message, that enable the extra functionality.  The 
JShell interface is also include via those commands - perhaps loadLibrary will 
be supported in the future.

Anyway, let me know what you think and what else you might need for possible 
inclusion of this patch.

Best,
Dave


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/CMakeLists.txt
  lldb/bindings/CMakeLists.txt
  lldb/bindings/java/CMakeLists.txt
  lldb/bindings/java/SWIG/LldbScriptInterpreter.java
  lldb/bindings/java/java-swigsafecast.swig
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java-wrapper.swig
  lldb/bindings/java/java.swig
  lldb/cmake/modules/FindJavaAndSwig.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/docs/resources/build.rst
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/API/CMakeLists.txt
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/liblldb-private.exports
  lldb/source/API/liblldb.exports
  lldb/source/Commands/CommandObjectBreakpointCommand.cpp
  lldb/source/Commands/CommandObjectScript.cpp
  lldb/source/Commands/CommandObjectWatchpointCommand.cpp
  lldb/source/Interpreter/OptionArgParser.cpp
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Java/Java.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/Java.h
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.cpp
  lldb/source/Plugins/ScriptInterpreter/Java/ScriptInterpreterJava.h
  lldb/test/CMakeLists.txt
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/independent_state.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/nested_sessions_2.in
  lldb/test/Shell/ScriptInterpreter/Java/Inputs/testmodule.java
  lldb/test/Shell/ScriptInterpreter/Java/bindings.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_function_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/breakpoint_oneline_callback.test
  lldb/test/Shell/ScriptInterpreter/Java/command_script_import.test
  lldb/test/Shell/ScriptInterpreter/Java/convenience_variables.test
  lldb/test/Shell/ScriptInterpreter/Java/fail_breakpoint_oneline.test
  lldb/test/Shell/ScriptInterpreter/Java/independent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/io.test
  lldb/test/Shell/ScriptInterpreter/Java/java-python.test
  lldb/test/Shell/ScriptInterpreter/Java/java.test
  lldb/test/Shell/ScriptInterpreter/Java/lit.local.cfg
  lldb/test/Shell/ScriptInterpreter/Java/nested_sessions.test
  lldb/test/Shell/ScriptInterpreter/Java/partial_statements.test
  lldb/test/Shell/ScriptInterpreter/Java/persistent_state.test
  lldb/test/Shell/ScriptInterpreter/Java/print.test
  lldb/test/Shell/ScriptInterpreter/Java/quit.test
  lldb/test/Shell/ScriptInterpreter/Java/watchpoint_callback.test
  lldb/test/Shell/lit.cfg.py
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.cfg.py
  lldb/unittests/ScriptInterpreter/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/CMakeLists.txt
  lldb/unittests/ScriptInterpreter/Java/JavaTests.cpp
  lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp

Index: lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
===
--- /dev/null
+++ lldb/unittests/ScriptInterpreter/Java/ScriptInterpreterTests.cpp
@@ -0,0 +1,59 @@
+//===-- JavaTests.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-Licen

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Sounds good.  When we started adding extension points for python, we made the 
implementations be free functions.  But then over time we realized it was often 
more convenient if you had a object managing the callback, that way it could 
more easily store state over the invocations, etc.  If doing free functions is 
harder in Java, I think it would be fine to only implement the "class with an 
invocation method" version of the callback.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

Discussing it with developers here, they agreed with your opinion that we 
really really ought to do 2.  😊

As you just noted, 3 is trickier.  Java doesn't really have a REPL.  It has 
jshell - we're not sure that counts.  In any case, am up for tackling 2.  Will 
keep you posted - might take me a bit.  In the meantime, happy to hear any 
further thoughts, advice, etc.

Thanks!



From: lldb-commits  on behalf of David 
Millar via lldb-commits 
Sent: Friday, October 8, 2021 2:44:06 PM
To: anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
teempe...@gmail.com; medismail.benn...@gmail.com; jo...@devlieghere.com; 
tedw...@quicinc.com; jmole...@apple.com; syaghm...@apple.com; 
jing...@apple.com; v...@apple.com; boris.ulasev...@gmail.com; 
lldb-commits@lists.llvm.org; h.imai@nitech.jp; bruce.mitche...@gmail.com; 
david.spick...@linaro.org; quic_soura...@quicinc.com; 
djordje.todoro...@syrmia.com; serhiy.re...@gmail.com; liburd1...@outlook.com; 
Jim Ingham
Subject: Re: [Lldb-commits] [PATCH] D111409 : 
proposed support for Java interface to Scripting Bridge

Just to clarify my use case:  I am one of the developers for a 
reverse-engineering tool called Ghidra.  Part of the tool is debugging-support 
to allow cross-over between dynamic and static analysis.  We currently support 
windbg/kd, the gcc MI2 interface, and direct Java debugging.  I have a working 
prototype for lldb, but it requires users to patch and rebuild lldb, which may 
be a heavy lift for some.  While it falls outside of my use case, I am quite 
willing to attempt implementing pieces 2 & 3 from Mr. Ingham's post.



From: Jim Ingham via Phabricator 
Sent: Friday, October 8, 2021 2:31:13 PM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
teempe...@gmail.com; medismail.benn...@gmail.com; jo...@devlieghere.com; 
tedw...@quicinc.com; jmole...@apple.com; syaghm...@apple.com; 
jing...@apple.com; v...@apple.com; boris.ulasev...@gmail.com; 
lldb-commits@lists.llvm.org; h.imai@nitech.jp; bruce.mitche...@gmail.com; 
david.spick...@linaro.org; quic_soura...@quicinc.com; 
djordje.todoro...@syrmia.com; serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409 : proposed support 
for Java interface to Scripting Bridge

jingham added a comment.

Support for a scripting language in lldb has three distinct pieces.

1. Making the SB API's available to the scripting languages
2. Adding all the callbacks so the scripting language can be used for 
breakpoint callbacks, data formatters, etc.
3. Adding a REPL for that language to the "script" command

This patch does #1, but not #2 & #3.  Do we care about whether new scripting 
languages will be able to provide the full "scripting language" experience?  
Does there need to be some plan for this before we add on the task of 
supporting the language?  Maybe it's okay to say "a REPL's too hard, and not 
worth it" but we should have a plan for adding in the callback interfaces?  Do 
we want to have somewhere you can advertise levels of support?  I would be sad 
to spend some time using a scripting language for lldb only to find it doesn't 
allow me to write breakpoint callbacks, for instance.

This is language #3 so it seems like a fit time to discuss this...

Repository:

  rLLDB LLDB

CHANGES SINCE LAST ACTION

  https://reviews.llvm.org/D111409/new/

https://reviews.llvm.org/D111409


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

In D111409#3052192 , @d-millar wrote:

> Just to clarify my use case:  I am one of the developers for a 
> reverse-engineering tool called Ghidra.  Part of the tool is 
> debugging-support to allow cross-over between dynamic and static analysis.  
> We currently support windbg/kd, the gcc MI2 interface, and direct Java 
> debugging.  I have a working prototype for lldb, but it requires users to 
> patch and rebuild lldb, which may be a heavy lift for some.  While it falls 
> outside of my use case, I am quite willing to attempt implementing pieces 2 & 
> 3 from Mr. Ingham's post.

That would be great!

To be clear, I was more asking questions than stating requirements.  It might 
be that the community feels it's sufficiently valuable to just have the API 
wrappers, and maintaining that in tree is fine provided someone is around to 
keep it up to date.  IMO, the callback affordances add much of the power in 
having a scripting language in the debugger, so it would be a shame not to take 
on the added complexity of another language and not have this bit working.  
Whether a REPL is possible is in part determined by whether the language in 
question is really amenable to that.  It's a huge convenience for developers, 
and it is pretty cool to be able to drop into the script interpreter and write 
a quick loop to find something in a bunch of objects.  But it isn't the core 
part of the job the extension language is doing.

> 
>
> From: Jim Ingham via Phabricator 
> Sent: Friday, October 8, 2021 2:31:13 PM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> teempe...@gmail.com; medismail.benn...@gmail.com; jo...@devlieghere.com; 
> tedw...@quicinc.com; jmole...@apple.com; syaghm...@apple.com; 
> jing...@apple.com; v...@apple.com; boris.ulasev...@gmail.com; 
> lldb-commits@lists.llvm.org; h.imai@nitech.jp; bruce.mitche...@gmail.com; 
> david.spick...@linaro.org; quic_soura...@quicinc.com; 
> djordje.todoro...@syrmia.com; serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409 : proposed support 
> for Java interface to Scripting Bridge
>
> jingham added a comment.
>
> Support for a scripting language in lldb has three distinct pieces.
>
> 1. Making the SB API's available to the scripting languages
> 2. Adding all the callbacks so the scripting language can be used for 
> breakpoint callbacks, data formatters, etc.
> 3. Adding a REPL for that language to the "script" command
>
> This patch does #1, but not #2 & #3.  Do we care about whether new scripting 
> languages will be able to provide the full "scripting language" experience?  
> Does there need to be some plan for this before we add on the task of 
> supporting the language?  Maybe it's okay to say "a REPL's too hard, and not 
> worth it" but we should have a plan for adding in the callback interfaces?  
> Do we want to have somewhere you can advertise levels of support?  I would be 
> sad to spend some time using a scripting language for lldb only to find it 
> doesn't allow me to write breakpoint callbacks, for instance.
>
> This is language #3 so it seems like a fit time to discuss this...
>
> Repository:
>
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>
>   https://reviews.llvm.org/D111409/new/
>
> https://reviews.llvm.org/D111409




Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

Just to clarify my use case:  I am one of the developers for a 
reverse-engineering tool called Ghidra.  Part of the tool is debugging-support 
to allow cross-over between dynamic and static analysis.  We currently support 
windbg/kd, the gcc MI2 interface, and direct Java debugging.  I have a working 
prototype for lldb, but it requires users to patch and rebuild lldb, which may 
be a heavy lift for some.  While it falls outside of my use case, I am quite 
willing to attempt implementing pieces 2 & 3 from Mr. Ingham's post.


From: Jim Ingham via Phabricator 
Sent: Friday, October 8, 2021 2:31:13 PM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
teempe...@gmail.com; medismail.benn...@gmail.com; jo...@devlieghere.com; 
tedw...@quicinc.com; jmole...@apple.com; syaghm...@apple.com; 
jing...@apple.com; v...@apple.com; boris.ulasev...@gmail.com; 
lldb-commits@lists.llvm.org; h.imai@nitech.jp; bruce.mitche...@gmail.com; 
david.spick...@linaro.org; quic_soura...@quicinc.com; 
djordje.todoro...@syrmia.com; serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

jingham added a comment.

Support for a scripting language in lldb has three distinct pieces.

1. Making the SB API's available to the scripting languages
2. Adding all the callbacks so the scripting language can be used for 
breakpoint callbacks, data formatters, etc.
3. Adding a REPL for that language to the "script" command

This patch does #1, but not #2 & #3.  Do we care about whether new scripting 
languages will be able to provide the full "scripting language" experience?  
Does there need to be some plan for this before we add on the task of 
supporting the language?  Maybe it's okay to say "a REPL's too hard, and not 
worth it" but we should have a plan for adding in the callback interfaces?  Do 
we want to have somewhere you can advertise levels of support?  I would be sad 
to spend some time using a scripting language for lldb only to find it doesn't 
allow me to write breakpoint callbacks, for instance.

This is language #3 so it seems like a fit time to discuss this...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Support for a scripting language in lldb has three distinct pieces.

1. Making the SB API's available to the scripting languages
2. Adding all the callbacks so the scripting language can be used for 
breakpoint callbacks, data formatters, etc.
3. Adding a REPL for that language to the "script" command

This patch does #1, but not #2 & #3.  Do we care about whether new scripting 
languages will be able to provide the full "scripting language" experience?  
Does there need to be some plan for this before we add on the task of 
supporting the language?  Maybe it's okay to say "a REPL's too hard, and not 
worth it" but we should have a plan for adding in the callback interfaces?  Do 
we want to have somewhere you can advertise levels of support?  I would be sad 
to spend some time using a scripting language for lldb only to find it doesn't 
allow me to write breakpoint callbacks, for instance.

This is language #3 so it seems like a fit time to discuss this...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

Ah, OK, after more digging, I realize I have probably provided only half of 
what you would like for this commit.  My primary intention was to expose the SB 
API so I could make calls from Java into it, but for it to be, in some sense, a 
full-fledged member of the API, it would make sense to enable Java scripting 
from lldb.  I will attempt to fill out that side of the equation.  Cheers, D



From: lldb-commits  on behalf of David 
Millar via lldb-commits 
Sent: Friday, October 8, 2021 1:22:07 PM
To: anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com; Raphael Isemann
Subject: Re: [Lldb-commits] [PATCH] D111409 : 
proposed support for Java interface to Scripting Bridge

I'm not sure I understand your testing strategy, in particular how it applies 
to the existing Lua and Python extensions.  I am looking at the files in 
lldb/unittests/ScriptInterpreter/Lua&Python.  Do you execute test from native 
Lua/Python environments or through C wrappers-only?  You mentioned a bot - is 
that code in the main repository?



From: Raphael Isemann via Phabricator 
Sent: Friday, October 8, 2021 11:24:10 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409 : proposed support 
for Java interface to Scripting Bridge

teemperor added a comment.

No problem, first time using Phabricator is always a bit confusing. You can 
just do a `git diff -U99 > ~/java-patch.diff`, click the "Update Diff" 
button on the top right of this website and then select *just* this diff file 
that contains your changes. Phabricator will render the diff properly for you 
(-> it will hide all the diff context by default). There is need to attach a 
separate diff file or anything else (users can just download the diff you 
uploaded).

Regarding the tests: We would essentially just need some basic test that 
exercises the new API a bit so that we know this works. The test code itself 
will be straightforward, but we would need a nice way to (automatically) find 
the system JRE and then set it up to be able to run the test code.

In D111409#3051140  
https://reviews.llvm.org/D111409#3051140, @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.
>
> 
>
> From: Raphael Isemann via Phabricator 
> Sent: Friday, October 8, 2021 10:46:50 AM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
> jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
> boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
> bruce.mitche...@gmail.com; david.spick...@linaro.org; 
> quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
> serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409  
> https://reviews.llvm.org/D111409: proposed support for Java interface to 
> Scripting Bridge
>
> teemperor added a comment.
>
> In D111409#3051110  
> https://reviews.llvm.org/D111409#3051110 
> https://reviews.llvm.org/D111409#3051110, @d-millar wrote:
>
>> Apologies for the inclusion of that last file "patch" - that is the "git 
>> diff -U999" result, should that be useful.
>
> You can just upload that diff file and Phabricator will display it properly. 
> There is no need to include the raw diff as part of the patch itself (it just 
> makes this diff 100 times larger than it needs to be) :)
>
> Anyway, I think this seems like a reasonable thing to have. We have to figure 
> out though how we can properly set up some Java tests for this and it would 
> be nice if we also find a bot that could actually run the tests

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

I'm not sure I understand your testing strategy, in particular how it applies 
to the existing Lua and Python extensions.  I am looking at the files in 
lldb/unittests/ScriptInterpreter/Lua&Python.  Do you execute test from native 
Lua/Python environments or through C wrappers-only?  You mentioned a bot - is 
that code in the main repository?


From: Raphael Isemann via Phabricator 
Sent: Friday, October 8, 2021 11:24:10 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

teemperor added a comment.

No problem, first time using Phabricator is always a bit confusing. You can 
just do a `git diff -U99 > ~/java-patch.diff`, click the "Update Diff" 
button on the top right of this website and then select *just* this diff file 
that contains your changes. Phabricator will render the diff properly for you 
(-> it will hide all the diff context by default). There is need to attach a 
separate diff file or anything else (users can just download the diff you 
uploaded).

Regarding the tests: We would essentially just need some basic test that 
exercises the new API a bit so that we know this works. The test code itself 
will be straightforward, but we would need a nice way to (automatically) find 
the system JRE and then set it up to be able to run the test code.

In D111409#3051140 , @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.
>
> 
>
> From: Raphael Isemann via Phabricator 
> Sent: Friday, October 8, 2021 10:46:50 AM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
> jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
> boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
> bruce.mitche...@gmail.com; david.spick...@linaro.org; 
> quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
> serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409 : proposed support 
> for Java interface to Scripting Bridge
>
> teemperor added a comment.
>
> In D111409#3051110  
> https://reviews.llvm.org/D111409#3051110, @d-millar wrote:
>
>> Apologies for the inclusion of that last file "patch" - that is the "git 
>> diff -U999" result, should that be useful.
>
> You can just upload that diff file and Phabricator will display it properly. 
> There is no need to include the raw diff as part of the patch itself (it just 
> makes this diff 100 times larger than it needs to be) :)
>
> Anyway, I think this seems like a reasonable thing to have. We have to figure 
> out though how we can properly set up some Java tests for this and it would 
> be nice if we also find a bot that could actually run the tests for us.
>
>
>
>
> Comment at: lldb/bindings/java/CMakeLists.txt:3
> + * IP: Apache License 2.0 with LLVM Exceptions
> + */
>
> +add_custom_command(
> 
>
> I don't think CMake accepts this as a comment and I think we anyway don't put 
> license headers in CMake scripts.
>
>
>
>
> Comment at: lldb/source/API/CMakeLists.txt:84
>
>   SBTrace.cpp
>
> +  SBTraceOptions.cpp
>
>   SBType.cpp
>
> 
>
> I think this is some conflict with one of the SBTrace patches.
>
> Repository:
>
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>
>   https://reviews.llvm.org/D111409/new/
>
> https://reviews.llvm.org/D111409




Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 378288.
d-millar added a comment.

FIx for potential conflicts with master.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java.swig
  lldb/source/API/CMakeLists.txt


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -81,7 +81,6 @@
   SBThreadCollection.cpp
   SBThreadPlan.cpp
   SBTrace.cpp
-  SBTraceOptions.cpp
   SBType.cpp
   SBTypeCategory.cpp
   SBTypeEnumMember.cpp
@@ -203,13 +202,7 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if (MSVC)
-  # Only MSVC has the ABI compatibility problem and avoids using 
FindPythonLibs,
-  # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (LLDB_ENABLE_PYTHON)
-target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
-  endif()
-else()
+if (NOT MSVC)
   set_target_properties(liblldb
 PROPERTIES
 OUTPUT_NAME lldb
Index: lldb/bindings/java/java.swig
===
--- lldb/bindings/java/java.swig
+++ lldb/bindings/java/java.swig
@@ -1,6 +1,3 @@
-/* ###
- * IP: Apache License 2.0 with LLVM Exceptions
- */
 /*
lldb.swig
 
Index: lldb/bindings/java/java-typemaps.swig
===
--- lldb/bindings/java/java-typemaps.swig
+++ lldb/bindings/java/java-typemaps.swig
@@ -1,6 +1,3 @@
-/* ###
- * IP: Apache License 2.0 with LLVM Exceptions
- */
 %include 
 %include 
 %include 


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -81,7 +81,6 @@
   SBThreadCollection.cpp
   SBThreadPlan.cpp
   SBTrace.cpp
-  SBTraceOptions.cpp
   SBType.cpp
   SBTypeCategory.cpp
   SBTypeEnumMember.cpp
@@ -203,13 +202,7 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if (MSVC)
-  # Only MSVC has the ABI compatibility problem and avoids using FindPythonLibs,
-  # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (LLDB_ENABLE_PYTHON)
-target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
-  endif()
-else()
+if (NOT MSVC)
   set_target_properties(liblldb
 PROPERTIES
 OUTPUT_NAME lldb
Index: lldb/bindings/java/java.swig
===
--- lldb/bindings/java/java.swig
+++ lldb/bindings/java/java.swig
@@ -1,6 +1,3 @@
-/* ###
- * IP: Apache License 2.0 with LLVM Exceptions
- */
 /*
lldb.swig
 
Index: lldb/bindings/java/java-typemaps.swig
===
--- lldb/bindings/java/java-typemaps.swig
+++ lldb/bindings/java/java-typemaps.swig
@@ -1,6 +1,3 @@
-/* ###
- * IP: Apache License 2.0 with LLVM Exceptions
- */
 %include 
 %include 
 %include 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 378282.
d-millar added a comment.

Another (hopefully cleaner) attempt.  If the addition of SBTraceOptions in 
lldb/source/API/CMakelists.txt conflicts, please feel free to delete it.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/CMakeLists.txt
  lldb/bindings/CMakeLists.txt
  lldb/bindings/java/CMakeLists.txt
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java.swig
  lldb/cmake/modules/FindJavaAndSwig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/source/API/CMakeLists.txt
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/liblldb-private.exports
  lldb/source/API/liblldb.exports

Index: lldb/source/API/liblldb.exports
===
--- lldb/source/API/liblldb.exports
+++ lldb/source/API/liblldb.exports
@@ -1,4 +1,7 @@
 _ZN4lldb*
 _ZNK4lldb*
+_ZN12lldb*
+_ZNK12lldb*
 init_lld*
 PyInit__lldb*
+Java*
Index: lldb/source/API/liblldb-private.exports
===
--- lldb/source/API/liblldb-private.exports
+++ lldb/source/API/liblldb-private.exports
@@ -4,3 +4,4 @@
 _ZNK12lldb_private*
 init_lld*
 PyInit__lldb*
+Java*
Index: lldb/source/API/SBDebugger.cpp
===
--- lldb/source/API/SBDebugger.cpp
+++ lldb/source/API/SBDebugger.cpp
@@ -736,6 +736,9 @@
   AddBoolConfigEntry(
   *config_up, "lua", LLDB_ENABLE_LUA,
   "A boolean value that indicates if lua support is enabled in LLDB");
+  AddBoolConfigEntry(
+  *config_up, "java", LLDB_ENABLE_JAVA,
+  "A boolean value that indicates if java support is enabled in LLDB");
   AddLLVMTargets(*config_up);
 
   SBStructuredData data;
Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -19,6 +19,11 @@
   set(lldb_lua_wrapper ${lua_bindings_dir}/LLDBWrapLua.cpp)
 endif()
 
+if(LLDB_ENABLE_JAVA)
+  get_target_property(java_bindings_dir swig_wrapper_java BINARY_DIR)
+  set(lldb_java_wrapper ${java_bindings_dir}/LLDBWrapJava.cpp)
+endif()
+
 add_lldb_library(liblldb SHARED ${option_framework}
   SBAddress.cpp
   SBAttachInfo.cpp
@@ -76,6 +81,7 @@
   SBThreadCollection.cpp
   SBThreadPlan.cpp
   SBTrace.cpp
+  SBTraceOptions.cpp
   SBType.cpp
   SBTypeCategory.cpp
   SBTypeEnumMember.cpp
@@ -92,6 +98,7 @@
   SystemInitializerFull.cpp
   ${lldb_python_wrapper}
   ${lldb_lua_wrapper}
+  ${lldb_java_wrapper}
 
   LINK_LIBS
 lldbBase
@@ -160,6 +167,21 @@
   set_source_files_properties(${lldb_lua_wrapper} PROPERTIES GENERATED ON)
 endif()
 
+if(LLDB_ENABLE_JAVA)
+  add_dependencies(liblldb swig_wrapper_java)
+  target_include_directories(liblldb PRIVATE ${JAVA_INCLUDE_DIR})
+  target_include_directories(liblldb PRIVATE ${JAVA_INCLUDE_DIR}/darwin)
+
+  if (MSVC)
+set_property(SOURCE ${lldb_java_wrapper} APPEND_STRING PROPERTY COMPILE_FLAGS " /W0")
+  else()
+set_property(SOURCE ${lldb_java_wrapper} APPEND_STRING PROPERTY COMPILE_FLAGS " ")
+  endif()
+
+  set_source_files_properties(${lldb_java_wrapper} PROPERTIES GENERATED ON)
+endif()
+
+
 set_target_properties(liblldb
   PROPERTIES
   VERSION ${LLDB_VERSION}
@@ -181,7 +203,13 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if (NOT MSVC)
+if (MSVC)
+  # Only MSVC has the ABI compatibility problem and avoids using FindPythonLibs,
+  # so only it needs to explicitly link against ${Python3_LIBRARIES}
+  if (LLDB_ENABLE_PYTHON)
+target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
+  endif()
+else()
   set_target_properties(liblldb
 PROPERTIES
 OUTPUT_NAME lldb
Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -41,6 +41,8 @@
 
 #cmakedefine01 LLDB_ENABLE_LIBXML2
 
+#cmakedefine01 LLDB_ENABLE_JAVA
+
 #cmakedefine01 LLDB_ENABLE_LUA
 
 #cmakedefine01 LLDB_ENABLE_PYTHON
Index: lldb/cmake/modules/FindJavaAndSwig.cmake
===
--- /dev/null
+++ lldb/cmake/modules/FindJavaAndSwig.cmake
@@ -0,0 +1,32 @@
+#.rst:
+# FindJavaAndSwig
+# --
+#
+# Find Java and SWIG as a whole.
+
+#if(JAVA_LIBRARIES AND JAVA_INCLUDE_DIR AND SWIG_EXECUTABLE)
+if(SWIG_EXECUTABLE)
+  set(JAVAANDSWIG_FOUND TRUE)
+else()
+  find_package(SWIG 2.0)
+  if (SWIG_FOUND)
+find_package(Java 11.0)
+if(JAVA_FOUND AND SWIG_FOUND)
+  mark_as_advanced(
+JAVA_LIBRARIES
+JAVA_INCLUDE_DIR
+SWIG_EXECUTABLE)
+endif()
+  else()
+message(STATUS "SWIG 2 or later is required for Java support in LLDB but could not be found")
+  endif()
+
+  include(FindPackageHandleStandardArgs)
+  find_package_handle_

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Med Ismail Bennani via Phabricator via lldb-commits]

mib added a comment.

In D111409#3051556 , @d-millar wrote:

> Hmmm, well, have tried running "git clang-format" with a few different 
> invocations, but seem to always get "No modified files to format."  
> Suggestions?

I was confused by the `patch` file, since it included the entire 
`SBDebugger.cpp`, I thought you were adding all that code.
Since clang-format mostly cares about C/Objective-C/C++ files, I guess you're 
fine with the formatting.  However, it looks like the `patch` file is still 
here.

To remove it from the diff, make sure you delete it from your local repository, 
add all your changes to the git index (`git add `) and make a commit. 
Then, create your new patch (`git show HEAD -U99 > mypatch.patch`) and 
update the differential by uploading the new patch (`mypatch.patch`). While 
doing so, you can review your changes and make sure you didn't included the 
`patch` file in the differential.

Thanks!


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

Hmmm, well, have tried running "git clang-format" with a few different 
invocations, but seem to always get "No modified files to format."  Suggestions?



From: David Millar via Phabricator 
Sent: Friday, October 8, 2021 11:33:37 AM
To: David Millar; teempe...@gmail.com
Subject: [PATCH] D111409 : proposed support 
for Java interface to Scripting Bridge

d-millar added a comment.

Merde - I followed you instructions but forgot to run clang-format.  Give me a 
minute



From: Raphael Isemann via Phabricator 
Sent: Friday, October 8, 2021 11:24:10 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409  
https://reviews.llvm.org/D111409: proposed support for Java interface to 
Scripting Bridge

teemperor added a comment.

No problem, first time using Phabricator is always a bit confusing. You can 
just do a `git diff -U99 > ~/java-patch.diff`, click the "Update Diff" 
button on the top right of this website and then select *just* this diff file 
that contains your changes. Phabricator will render the diff properly for you 
(-> it will hide all the diff context by default). There is need to attach a 
separate diff file or anything else (users can just download the diff you 
uploaded).

Regarding the tests: We would essentially just need some basic test that 
exercises the new API a bit so that we know this works. The test code itself 
will be straightforward, but we would need a nice way to (automatically) find 
the system JRE and then set it up to be able to run the test code.

In D111409#3051140  
https://reviews.llvm.org/D111409#3051140 
https://reviews.llvm.org/D111409#3051140, @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.
>
> 
>
> From: Raphael Isemann via Phabricator 
> Sent: Friday, October 8, 2021 10:46:50 AM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
> jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
> boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
> bruce.mitche...@gmail.com; david.spick...@linaro.org; 
> quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
> serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409  
> https://reviews.llvm.org/D111409 https://reviews.llvm.org/D111409: proposed 
> support for Java interface to Scripting Bridge
>
> teemperor added a comment.
>
> In D111409#3051110  
> https://reviews.llvm.org/D111409#3051110 
> https://reviews.llvm.org/D111409#3051110 
> https://reviews.llvm.org/D111409#3051110, @d-millar wrote:
>
>> Apologies for the inclusion of that last file "patch" - that is the "git 
>> diff -U999" result, should that be useful.
>
> You can just upload that diff file and Phabricator will display it properly. 
> There is no need to include the raw diff as part of the patch itself (it just 
> makes this diff 100 times larger than it needs to be) :)
>
> Anyway, I think this seems like a reasonable thing to have. We have to figure 
> out though how we can properly set up some Java tests for this and it would 
> be nice if we also find a bot that could actually run the tests for us.
>
> Comment at: lldb/bindings/java/CMakeLists.txt:3
> + * IP: Apache License 2.0 with LLVM Exceptions
> + */
>
> +add_custom_command(
> 
>
> I don't think CMake accepts this as a comment and I think we anyway don't put 
> license headers in CMake scripts.
>
> Comment at: lldb/source/API/CMakeLists.txt:84
>
>   SBTrace.cpp
>
> +  SBTraceOptions.cpp
>
>   SBType.cpp
>
> 
>
> I think this is some conflict with one of the SBTrace patches.
>
> Repository:
>
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>
>   https://reviews.llvm.org/D111409/new/
>
> https://reviews.llvm.org/D111409

Repository:

  rLLDB LLDB

CHANGES SINCE LAST ACTION

  https://reviews.llvm.org/D111409/new/

https://reviews.llvm.org/D111409

Repository:

  rLLDB LLDB

CHANGES SIN

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

Merde - I followed you instructions but forgot to run clang-format.  Give me a 
minute


From: Raphael Isemann via Phabricator 
Sent: Friday, October 8, 2021 11:24:10 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

teemperor added a comment.

No problem, first time using Phabricator is always a bit confusing. You can 
just do a `git diff -U99 > ~/java-patch.diff`, click the "Update Diff" 
button on the top right of this website and then select *just* this diff file 
that contains your changes. Phabricator will render the diff properly for you 
(-> it will hide all the diff context by default). There is need to attach a 
separate diff file or anything else (users can just download the diff you 
uploaded).

Regarding the tests: We would essentially just need some basic test that 
exercises the new API a bit so that we know this works. The test code itself 
will be straightforward, but we would need a nice way to (automatically) find 
the system JRE and then set it up to be able to run the test code.

In D111409#3051140 , @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.
>
> 
>
> From: Raphael Isemann via Phabricator 
> Sent: Friday, October 8, 2021 10:46:50 AM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
> jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
> boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
> bruce.mitche...@gmail.com; david.spick...@linaro.org; 
> quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
> serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409 : proposed support 
> for Java interface to Scripting Bridge
>
> teemperor added a comment.
>
> In D111409#3051110  
> https://reviews.llvm.org/D111409#3051110, @d-millar wrote:
>
>> Apologies for the inclusion of that last file "patch" - that is the "git 
>> diff -U999" result, should that be useful.
>
> You can just upload that diff file and Phabricator will display it properly. 
> There is no need to include the raw diff as part of the patch itself (it just 
> makes this diff 100 times larger than it needs to be) :)
>
> Anyway, I think this seems like a reasonable thing to have. We have to figure 
> out though how we can properly set up some Java tests for this and it would 
> be nice if we also find a bot that could actually run the tests for us.
>
>
>
>
> Comment at: lldb/bindings/java/CMakeLists.txt:3
> + * IP: Apache License 2.0 with LLVM Exceptions
> + */
>
> +add_custom_command(
> 
>
> I don't think CMake accepts this as a comment and I think we anyway don't put 
> license headers in CMake scripts.
>
>
>
>
> Comment at: lldb/source/API/CMakeLists.txt:84
>
>   SBTrace.cpp
>
> +  SBTraceOptions.cpp
>
>   SBType.cpp
>
> 
>
> I think this is some conflict with one of the SBTrace patches.
>
> Repository:
>
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>
>   https://reviews.llvm.org/D111409/new/
>
> https://reviews.llvm.org/D111409




Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar updated this revision to Diff 378237.
d-millar added a comment.

supplying a better patch file


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

Files:
  lldb/bindings/java/CMakeLists.txt
  patch

Index: patch
===
--- patch
+++ /dev/null
@@ -1,2403 +0,0 @@
-diff --git a/lldb/CMakeLists.txt b/lldb/CMakeLists.txt
-index 594c769141b4..faf3846a0a16 100644
 a/lldb/CMakeLists.txt
-+++ b/lldb/CMakeLists.txt
-@@ -1,106 +1,106 @@
- cmake_minimum_required(VERSION 3.13.4)
- 
- # Add path for custom modules.
- set(CMAKE_MODULE_PATH
-   ${CMAKE_MODULE_PATH}
-   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
-   "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
-   )
- 
- # If we are not building as part of LLVM, build LLDB as a standalone project,
- # using LLVM as an external library.
- if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
-   project(lldb)
-   include(LLDBStandalone)
- 
-   set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
-   set(CMAKE_CXX_STANDARD_REQUIRED YES)
-   set(CMAKE_CXX_EXTENSIONS NO)
- endif()
- 
- include(LLDBConfig)
- include(AddLLDB)
- 
- # Define the LLDB_CONFIGURATION_xxx matching the build type.
- if(uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
-   add_definitions(-DLLDB_CONFIGURATION_DEBUG)
- endif()
- 
- if (WIN32)
-   add_definitions(-D_ENABLE_EXTENDED_ALIGNED_STORAGE)
- endif()
- 
- if (LLDB_ENABLE_PYTHON)
-   if (NOT CMAKE_CROSSCOMPILING)
- execute_process(
-   COMMAND ${Python3_EXECUTABLE}
-   -c "import distutils.sysconfig; print(distutils.sysconfig.get_python_lib(True, False, ''))"
-   OUTPUT_VARIABLE LLDB_PYTHON_DEFAULT_RELATIVE_PATH
-   OUTPUT_STRIP_TRAILING_WHITESPACE)
- 
- file(TO_CMAKE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH} LLDB_PYTHON_DEFAULT_RELATIVE_PATH)
-   else ()
- if ("${LLDB_PYTHON_RELATIVE_PATH}" STREQUAL "")
-   message(FATAL_ERROR
- "Crosscompiling LLDB with Python requires manually setting
- LLDB_PYTHON_RELATIVE_PATH.")
- endif ()
-   endif ()
- 
-   set(LLDB_PYTHON_RELATIVE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH}
- CACHE STRING "Path where Python modules are installed, relative to install prefix")
- endif ()
- 
--if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA)
-+if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA OR LLDB_ENABLE_JAVA)
-   add_subdirectory(bindings)
- endif ()
- 
- # We need the headers generated by instrinsics_gen before we can compile
- # any source file in LLDB as the imported Clang modules might include
- # some of these generated headers. This approach is copied from Clang's main
- # CMakeLists.txt, so it should kept in sync the code in Clang which was added
- # in llvm-svn 308844.
- if(LLVM_ENABLE_MODULES)
-   list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
- endif()
- 
- if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE AND NOT LLDB_TABLEGEN_EXE)
-   set(LLVM_USE_HOST_TOOLS ON)
-   include(CrossCompile)
-   if (NOT NATIVE_LLVM_DIR OR NOT NATIVE_Clang_DIR)
- message(FATAL_ERROR
-   "Crosscompiling standalone requires the variables NATIVE_{CLANG,LLVM}_DIR
-   for building the native lldb-tblgen used during the build process.")
-   endif()
-   llvm_create_cross_target(lldb NATIVE "" Release
- -DLLVM_DIR=${NATIVE_LLVM_DIR}
- -DClang_DIR=${NATIVE_Clang_DIR})
- endif()
- 
- # TableGen
- add_subdirectory(utils/TableGen)
- 
- add_subdirectory(source)
- add_subdirectory(tools)
- add_subdirectory(docs)
- 
- if (LLDB_ENABLE_PYTHON)
-   if(LLDB_BUILD_FRAMEWORK)
- set(lldb_python_target_dir "${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/Resources/Python/lldb")
-   else()
- set(lldb_python_target_dir "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
-   endif()
-   get_target_property(lldb_python_bindings_dir swig_wrapper_python BINARY_DIR)
-   finish_swig_python("lldb-python" "${lldb_python_bindings_dir}" "${lldb_python_target_dir}")
- endif()
- 
- option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." ${LLVM_INCLUDE_TESTS})
- if(LLDB_INCLUDE_TESTS)
-   add_subdirectory(test)
-   add_subdirectory(unittests)
-   add_subdirectory(utils)
- endif()
- 
- if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
-   llvm_distribution_add_targets()
- endif()
-diff --git a/lldb/bindings/CMakeLists.txt b/lldb/bindings/CMakeLists.txt
-index 9759b069fdc4..780413104d7f 100644
 a/lldb/bindings/CMakeLists.txt
-+++ b/lldb/bindings/CMakeLists.txt
-@@ -1,40 +1,45 @@
- file(GLOB SWIG_INTERFACES interface/*.i)
- file(GLOB_RECURSE SWIG_SOURCES *.swig)
- file(GLOB SWIG_HEADERS
-   ${LLDB_SOURCE_DIR}/include/lldb/API/*.h
-   ${LLDB_SOURCE_DIR}/include/lldb/*.h
- )
- file(GLOB SWIG_PRIVATE_HEADERS
-   ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h
- )
- foreach(private_header ${SWIG_PRIVATE_HEADERS})
-   list(REMOVE_ITEM SWIG_HEADERS ${private_header})
- endforeach()
- 
- if(LLDB_BUILD

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

No problem, first time using Phabricator is always a bit confusing. You can 
just do a `git diff -U99 > ~/java-patch.diff`, click the "Update Diff" 
button on the top right of this website and then select *just* this diff file 
that contains your changes. Phabricator will render the diff properly for you 
(-> it will hide all the diff context by default). There is need to attach a 
separate diff file or anything else (users can just download the diff you 
uploaded).

Regarding the tests: We would essentially just need some basic test that 
exercises the new API a bit so that we know this works. The test code itself 
will be straightforward, but we would need a nice way to (automatically) find 
the system JRE and then set it up to be able to run the test code.

In D111409#3051140 , @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.
>
> 
>
> From: Raphael Isemann via Phabricator 
> Sent: Friday, October 8, 2021 10:46:50 AM
> To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
> medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
> jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
> boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
> bruce.mitche...@gmail.com; david.spick...@linaro.org; 
> quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
> serhiy.re...@gmail.com; liburd1...@outlook.com
> Cc: mgo...@gentoo.org
> Subject: [PATCH] D111409 : proposed support 
> for Java interface to Scripting Bridge
>
> teemperor added a comment.
>
> In D111409#3051110  
> https://reviews.llvm.org/D111409#3051110, @d-millar wrote:
>
>> Apologies for the inclusion of that last file "patch" - that is the "git 
>> diff -U999" result, should that be useful.
>
> You can just upload that diff file and Phabricator will display it properly. 
> There is no need to include the raw diff as part of the patch itself (it just 
> makes this diff 100 times larger than it needs to be) :)
>
> Anyway, I think this seems like a reasonable thing to have. We have to figure 
> out though how we can properly set up some Java tests for this and it would 
> be nice if we also find a bot that could actually run the tests for us.
>
>
>
>
> Comment at: lldb/bindings/java/CMakeLists.txt:3
> + * IP: Apache License 2.0 with LLVM Exceptions
> + */
>
> +add_custom_command(
> 
>
> I don't think CMake accepts this as a comment and I think we anyway don't put 
> license headers in CMake scripts.
>
>
>
>
> Comment at: lldb/source/API/CMakeLists.txt:84
>
>   SBTrace.cpp
>
> +  SBTraceOptions.cpp
>
>   SBType.cpp
>
> 
>
> I think this is some conflict with one of the SBTrace patches.
>
> Repository:
>
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>
>   https://reviews.llvm.org/D111409/new/
>
> https://reviews.llvm.org/D111409




Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Med Ismail Bennani via Phabricator via lldb-commits]

mib added a comment.

In D111409#3051140 , @d-millar wrote:

> Am obviously brand new to your process and a bit of an old dog when it comes 
> to learning new tricks.  Would you prefer I make a new submission with the 
> -U99 diff?   Also, am more than willing to help with the Java tests if 
> that would be useful.

Hi @d-millar,

Here are some ressources that will help you comply with the LLVM guidelines:

- Contributing to LLVM : https://llvm.org/docs/Contributing.html
- Code Reviews with Phabricator : https://llvm.org/docs/Phabricator.html

Do you mind updating this diff by removing the patch and running clang-format 
on your code ?

That would simplify code review for reviewers.

Thanks!


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

Re: [Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via lldb-commits]

Am obviously brand new to your process and a bit of an old dog when it comes to 
learning new tricks.  Would you prefer I make a new submission with the 
-U99 diff?   Also, am more than willing to help with the Java tests if that 
would be useful.


From: Raphael Isemann via Phabricator 
Sent: Friday, October 8, 2021 10:46:50 AM
To: David Millar; anoro...@apple.com; fallk...@yahoo.com; kkle...@redhat.com; 
medismail.benn...@gmail.com; jo...@devlieghere.com; tedw...@quicinc.com; 
jmole...@apple.com; syaghm...@apple.com; jing...@apple.com; v...@apple.com; 
boris.ulasev...@gmail.com; lldb-commits@lists.llvm.org; h.imai@nitech.jp; 
bruce.mitche...@gmail.com; david.spick...@linaro.org; 
quic_soura...@quicinc.com; djordje.todoro...@syrmia.com; 
serhiy.re...@gmail.com; liburd1...@outlook.com
Cc: mgo...@gentoo.org
Subject: [PATCH] D111409: proposed support for Java interface to Scripting 
Bridge

teemperor added a comment.

In D111409#3051110 , @d-millar wrote:

> Apologies for the inclusion of that last file "patch" - that is the "git diff 
> -U999" result, should that be useful.

You can just upload that diff file and Phabricator will display it properly. 
There is no need to include the raw diff as part of the patch itself (it just 
makes this diff 100 times larger than it needs to be) :)

Anyway, I think this seems like a reasonable thing to have. We have to figure 
out though how we can properly set up some Java tests for this and it would be 
nice if we also find a bot that could actually run the tests for us.




Comment at: lldb/bindings/java/CMakeLists.txt:3
+ * IP: Apache License 2.0 with LLVM Exceptions
+ */
+add_custom_command(

I don't think CMake accepts this as a comment and I think we anyway don't put 
license headers in CMake scripts.



Comment at: lldb/source/API/CMakeLists.txt:84
   SBTrace.cpp
+  SBTraceOptions.cpp
   SBType.cpp

I think this is some conflict with one of the SBTrace patches.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

In D111409#3051110 , @d-millar wrote:

> Apologies for the inclusion of that last file "patch" - that is the "git diff 
> -U999" result, should that be useful.

You can just upload that diff file and Phabricator will display it properly. 
There is no need to include the raw diff as part of the patch itself (it just 
makes this diff 100 times larger than it needs to be) :)

Anyway, I think this seems like a reasonable thing to have. We have to figure 
out though how we can properly set up some Java tests for this and it would be 
nice if we also find a bot that could actually run the tests for us.




Comment at: lldb/bindings/java/CMakeLists.txt:3
+ * IP: Apache License 2.0 with LLVM Exceptions
+ */
+add_custom_command(

I don't think CMake accepts this as a comment and I think we anyway don't put 
license headers in CMake scripts.



Comment at: lldb/source/API/CMakeLists.txt:84
   SBTrace.cpp
+  SBTraceOptions.cpp
   SBType.cpp

I think this is some conflict with one of the SBTrace patches.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

Apologies for the inclusion of that last file "patch" - that is the "git diff 
-U999" result, should that be useful.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D111409

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

[Lldb-commits] [PATCH] D111409: proposed support for Java interface to Scripting Bridge

[David Millar via Phabricator via lldb-commits]

d-millar created this revision.
d-millar added a reviewer: LLDB.
Herald added subscribers: teemperor, mgorny.
d-millar requested review of this revision.

The patch include files necessary to extend the Scripting Bridge API with Java. 
 The edits follow the existing patterns for Python and Lua.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D111409

Files:
  lldb/CMakeLists.txt
  lldb/bindings/CMakeLists.txt
  lldb/bindings/java/CMakeLists.txt
  lldb/bindings/java/java-typemaps.swig
  lldb/bindings/java/java.swig
  lldb/cmake/modules/FindJavaAndSwig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/source/API/CMakeLists.txt
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/liblldb-private.exports
  lldb/source/API/liblldb.exports
  patch

Index: patch
===
--- /dev/null
+++ patch
@@ -0,0 +1,2403 @@
+diff --git a/lldb/CMakeLists.txt b/lldb/CMakeLists.txt
+index 594c769141b4..faf3846a0a16 100644
+--- a/lldb/CMakeLists.txt
 b/lldb/CMakeLists.txt
+@@ -1,106 +1,106 @@
+ cmake_minimum_required(VERSION 3.13.4)
+ 
+ # Add path for custom modules.
+ set(CMAKE_MODULE_PATH
+   ${CMAKE_MODULE_PATH}
+   "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
+   "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
+   )
+ 
+ # If we are not building as part of LLVM, build LLDB as a standalone project,
+ # using LLVM as an external library.
+ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+   project(lldb)
+   include(LLDBStandalone)
+ 
+   set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to")
+   set(CMAKE_CXX_STANDARD_REQUIRED YES)
+   set(CMAKE_CXX_EXTENSIONS NO)
+ endif()
+ 
+ include(LLDBConfig)
+ include(AddLLDB)
+ 
+ # Define the LLDB_CONFIGURATION_xxx matching the build type.
+ if(uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
+   add_definitions(-DLLDB_CONFIGURATION_DEBUG)
+ endif()
+ 
+ if (WIN32)
+   add_definitions(-D_ENABLE_EXTENDED_ALIGNED_STORAGE)
+ endif()
+ 
+ if (LLDB_ENABLE_PYTHON)
+   if (NOT CMAKE_CROSSCOMPILING)
+ execute_process(
+   COMMAND ${Python3_EXECUTABLE}
+   -c "import distutils.sysconfig; print(distutils.sysconfig.get_python_lib(True, False, ''))"
+   OUTPUT_VARIABLE LLDB_PYTHON_DEFAULT_RELATIVE_PATH
+   OUTPUT_STRIP_TRAILING_WHITESPACE)
+ 
+ file(TO_CMAKE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH} LLDB_PYTHON_DEFAULT_RELATIVE_PATH)
+   else ()
+ if ("${LLDB_PYTHON_RELATIVE_PATH}" STREQUAL "")
+   message(FATAL_ERROR
+ "Crosscompiling LLDB with Python requires manually setting
+ LLDB_PYTHON_RELATIVE_PATH.")
+ endif ()
+   endif ()
+ 
+   set(LLDB_PYTHON_RELATIVE_PATH ${LLDB_PYTHON_DEFAULT_RELATIVE_PATH}
+ CACHE STRING "Path where Python modules are installed, relative to install prefix")
+ endif ()
+ 
+-if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA)
++if (LLDB_ENABLE_PYTHON OR LLDB_ENABLE_LUA OR LLDB_ENABLE_JAVA)
+   add_subdirectory(bindings)
+ endif ()
+ 
+ # We need the headers generated by instrinsics_gen before we can compile
+ # any source file in LLDB as the imported Clang modules might include
+ # some of these generated headers. This approach is copied from Clang's main
+ # CMakeLists.txt, so it should kept in sync the code in Clang which was added
+ # in llvm-svn 308844.
+ if(LLVM_ENABLE_MODULES)
+   list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
+ endif()
+ 
+ if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE AND NOT LLDB_TABLEGEN_EXE)
+   set(LLVM_USE_HOST_TOOLS ON)
+   include(CrossCompile)
+   if (NOT NATIVE_LLVM_DIR OR NOT NATIVE_Clang_DIR)
+ message(FATAL_ERROR
+   "Crosscompiling standalone requires the variables NATIVE_{CLANG,LLVM}_DIR
+   for building the native lldb-tblgen used during the build process.")
+   endif()
+   llvm_create_cross_target(lldb NATIVE "" Release
+ -DLLVM_DIR=${NATIVE_LLVM_DIR}
+ -DClang_DIR=${NATIVE_Clang_DIR})
+ endif()
+ 
+ # TableGen
+ add_subdirectory(utils/TableGen)
+ 
+ add_subdirectory(source)
+ add_subdirectory(tools)
+ add_subdirectory(docs)
+ 
+ if (LLDB_ENABLE_PYTHON)
+   if(LLDB_BUILD_FRAMEWORK)
+ set(lldb_python_target_dir "${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/Resources/Python/lldb")
+   else()
+ set(lldb_python_target_dir "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
+   endif()
+   get_target_property(lldb_python_bindings_dir swig_wrapper_python BINARY_DIR)
+   finish_swig_python("lldb-python" "${lldb_python_bindings_dir}" "${lldb_python_target_dir}")
+ endif()
+ 
+ option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." ${LLVM_INCLUDE_TESTS})
+ if(LLDB_INCLUDE_TESTS)
+   add_subdirectory(test)
+   add_subdirectory(unittests)
+   add_subdirectory(utils)
+ endif()
+ 
+ if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
+   llvm_distribution_add_targets()
+ endif()
+diff --git a/lldb/bindings/CMakeLists.txt b/lldb/bindings/CMakeLists.txt
+index 9759b069fdc4..780413104d7f 100644
+--- a/lldb/bindings/CMakeLists.txt
+++