[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, ));
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+} // namespace
+
+TEST_F(ScriptInterpreterTest, 

[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, ));
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+} // 

[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

[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.
+// 

[Lldb-commits] [PATCH] D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches

[David Millar via Phabricator via lldb-commits]

d-millar added a comment.

That discussion is extremely helpful - gives me good context for what I need to 
suport.  THANKS!



From: lldb-commits  on behalf of Jim 
Ingham via Phabricator via lldb-commits 
Sent: Friday, October 8, 2021 5:44:49 PM
To: vadi...@gmail.com; jing...@apple.com
Cc: djordje.todoro...@syrmia.com; lldb-commits@lists.llvm.org; 
liburd1...@outlook.com; quic_soura...@quicinc.com; h.imai@nitech.jp; 
serhiy.re...@gmail.com; david.spick...@linaro.org
Subject: [Lldb-commits] [PATCH] D109738 : 
[lldb] Fix bug 38317 - Address breakpoints don't work if set before the process 
launches

jingham added a comment.

I realized I typed this all down a while ago but forgot to hit submit.  I think 
I still agree with former me...

In D109738#3002257  
https://reviews.llvm.org/D109738#3002257, @vadimcn wrote:

> Hi Jim,
> I think there's a bit of confusion going on here:
> The original bug was opened by Ted Woodward, and I think his scenario was
> motivated by embedded debugging.   He also provided that example with a
> breakpoint being set in main.
>
> I've rediscovered this bug independently, while working on an IDE
> integration project.  In my case, the IDE saves just the address of the
> instruction where a breakpoint was set in the previous debugging session.

That is clearly wrong: an address is never enough to restore a breakpoint from 
one session to the next even if you can turn ASLR off.  After all, the 
breakpoint could be in a dlopened library.  That makes getting this breakpoint 
back to where it came from dependent on the path of execution.  For instance, 
if one library had been dlopened at the address in question and then dlclosed 
and then your target library dlopened in the same spot before the stop that set 
the breakpoint, then next time round you will set the breakpoint in the first 
library loaded not the second one, which is again not right.  Remember also 
that setting breakpoints is not a risk-free process.  On x86-64, for instance, 
you could end up setting the breakpoint not on an instruction boundary, you 
could set it in some data, etc.  All leading to hard-to-diagnose failures in 
the running process.  So some caution is warranted here.

Is it possible to get your IDE to record the module & the address?  WIth that 
pair, you can always set the breakpoint at the right place, and lldb allows you 
to specify a module as a filter when you set an address breakpoint, so there 
would be no problem with resetting it this way using the SB API's.

> In the next session, the debug adapter is expected to restore instruction
> breakpoints using just the absolute addresses; the protocol does not
> provide for any user interaction.  Also, this happens via the SB API, not
> via LLDB commands.   Fortunately, when ASLR is disabled, modules are
> usually loaded at the same address, so things tend to work out 99% of the
> time.  The other 1%... well, if you are debugging on the assembly
> instruction level, you are kinda expected to know what you are doing and be
> prepared to deal with problems like those you've described above.

lldb use on iOS is far above 1% of the lldb users.

> When the target is created, the modules for the target are loaded and
>
>> mapped at whatever address is their default load address.
>
> Clearly, this isn't happening.  From what I can see, section addresses are
> not known until the process starts running.   Maybe this is another bug
> that needs fixing?

Breakpoints eventually resolve to "breakpoint locations", which are specified 
by an lldb_private::Address.  When you set a file & line breakpoint, or a 
symbol name breakpoint we make always make a Section relative Address for the 
breakpoint location.  When the binary loads, provided its UUID hasn't changed 
we don't re-resolve the breakpoint, which would be wasted effort since we 
already know its section relative offset, and can use that to calculate the 
load address to send to the debug monitor.

So it is the case that we can make section relative addresses pre-run and 
resolve them on running.  In fact, when you ask lldb "image lookup -n main" 
before run, we will get the Address for the main symbol - a section relative 
Address - and print it at the "default" load address of the library.  So we 
deal with Section relative Addresses all the time pre run.  The only thing we 
don't know is the "load address" of the section, because the SectionLoadList 
isn't filled in pre-run.

When you set a breakpoint by address pre-run, if the address is uniquely in the 
default load range of some binary, we certainly CAN figure out the section and 
resolve it.  The important point about Ted's report is that in a case where we 
clearly could do that, we aren't.

> Even so, I think that address breakpoints should still function when
> section addresses aren't known at breakpoint creation time (for whatever
> 

[Lldb-commits] [PATCH] D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches

[David Millar via Phabricator via lldb-commits]

d-millar added subscribers: DavidSpickett, djtodoro, HirokiImai, jingham, 
ZeeZeeMorin, SouraVX, serhiy.redko, vadimcn, d-millar.
d-millar added a comment.

That discussion is extremely helpful - gives me good context for what I need to 
suport.  THANKS!



From: lldb-commits  on behalf of Jim 
Ingham via Phabricator via lldb-commits 
Sent: Friday, October 8, 2021 5:44:49 PM
To: vadi...@gmail.com; jing...@apple.com
Cc: djordje.todoro...@syrmia.com; lldb-commits@lists.llvm.org; 
liburd1...@outlook.com; quic_soura...@quicinc.com; h.imai@nitech.jp; 
serhiy.re...@gmail.com; david.spick...@linaro.org
Subject: [Lldb-commits] [PATCH] D109738 : 
[lldb] Fix bug 38317 - Address breakpoints don't work if set before the process 
launches

jingham added a comment.

I realized I typed this all down a while ago but forgot to hit submit.  I think 
I still agree with former me...

In D109738#3002257  
https://reviews.llvm.org/D109738#3002257, @vadimcn wrote:

> Hi Jim,
> I think there's a bit of confusion going on here:
> The original bug was opened by Ted Woodward, and I think his scenario was
> motivated by embedded debugging.   He also provided that example with a
> breakpoint being set in main.
>
> I've rediscovered this bug independently, while working on an IDE
> integration project.  In my case, the IDE saves just the address of the
> instruction where a breakpoint was set in the previous debugging session.

That is clearly wrong: an address is never enough to restore a breakpoint from 
one session to the next even if you can turn ASLR off.  After all, the 
breakpoint could be in a dlopened library.  That makes getting this breakpoint 
back to where it came from dependent on the path of execution.  For instance, 
if one library had been dlopened at the address in question and then dlclosed 
and then your target library dlopened in the same spot before the stop that set 
the breakpoint, then next time round you will set the breakpoint in the first 
library loaded not the second one, which is again not right.  Remember also 
that setting breakpoints is not a risk-free process.  On x86-64, for instance, 
you could end up setting the breakpoint not on an instruction boundary, you 
could set it in some data, etc.  All leading to hard-to-diagnose failures in 
the running process.  So some caution is warranted here.

Is it possible to get your IDE to record the module & the address?  WIth that 
pair, you can always set the breakpoint at the right place, and lldb allows you 
to specify a module as a filter when you set an address breakpoint, so there 
would be no problem with resetting it this way using the SB API's.

> In the next session, the debug adapter is expected to restore instruction
> breakpoints using just the absolute addresses; the protocol does not
> provide for any user interaction.  Also, this happens via the SB API, not
> via LLDB commands.   Fortunately, when ASLR is disabled, modules are
> usually loaded at the same address, so things tend to work out 99% of the
> time.  The other 1%... well, if you are debugging on the assembly
> instruction level, you are kinda expected to know what you are doing and be
> prepared to deal with problems like those you've described above.

lldb use on iOS is far above 1% of the lldb users.

> When the target is created, the modules for the target are loaded and
>
>> mapped at whatever address is their default load address.
>
> Clearly, this isn't happening.  From what I can see, section addresses are
> not known until the process starts running.   Maybe this is another bug
> that needs fixing?

Breakpoints eventually resolve to "breakpoint locations", which are specified 
by an lldb_private::Address.  When you set a file & line breakpoint, or a 
symbol name breakpoint we make always make a Section relative Address for the 
breakpoint location.  When the binary loads, provided its UUID hasn't changed 
we don't re-resolve the breakpoint, which would be wasted effort since we 
already know its section relative offset, and can use that to calculate the 
load address to send to the debug monitor.

So it is the case that we can make section relative addresses pre-run and 
resolve them on running.  In fact, when you ask lldb "image lookup -n main" 
before run, we will get the Address for the main symbol - a section relative 
Address - and print it at the "default" load address of the library.  So we 
deal with Section relative Addresses all the time pre run.  The only thing we 
don't know is the "load address" of the section, because the SectionLoadList 
isn't filled in pre-run.

When you set a breakpoint by address pre-run, if the address is uniquely in the 
default load range of some binary, we certainly CAN figure out the section and 
resolve it.  The important point about Ted's report is that in a case where we 
clearly could do that, we aren't.

> Even so, I 

[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

[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  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 for 

[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)
+  

[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 

[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()
- 
- 

[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