[lldb-dev] Remote connection expansion?

2020-11-04 Thread Mike Mestnik via lldb-dev 
I'm looking for support running lldb over ssh.  I can forward the
originating connection, but the run command is attempting to use
random ports on localhost to attain another connection.  This fails as
the localhost's are not the same.

Is there a platform, preferably real time, for lldb support?

One might ask why ssh, the basic answer is I don't want to open
*another port on my remote host...  Even if I did I'd still have the
same problem, a random port would fail to connect(this time because of
a firewall).  The main answer is, without ssh, lldb is limited to
running on local or VPN networks.  I'd rather use ssh than configure a
VPN for this one use case.

* lldb doesn't sound like something one would want to host, even if
connections were blocked from everywhere "else."

Now I'm attempting forward error correction by guessing where this
topic could lead.  I would be willing to expand the network code to
include domain sockets, to replace the whole idea of using, IMHO
barbaric, port numbers.  This work could potentially include direct
support for ssh.  I understand that this would likely be a breaking
change, is there version negotiation?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Need help with failing LLDB tests on Windows

2020-11-04 Thread Ted Woodward via lldb-dev 
To expand a bit on what Pavel has written, the lldb module should be in 
\lib\site-packages\lldb . In that directory is a file, _lldb.pyd, that 
should be a copy of \bin\liblldb.dll .

Do both files exist? Is _lldb.pyd a copy of liblldb.dll?
See function create_relative_symlink in llvm-project/lldb/CMakeLists.txt for 
the copy (on non-unix hosts) procedure.

Did you recently change your version of swig? LLDB requires swig 2, but, as you 
pointed out last year, there are issues with some versions of swig. We use 
4.0.1 on Windows.

> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, November 4, 2020 2:49 AM
> To: Adrian McCarthy ; LLDB  d...@lists.llvm.org>
> Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on Windows
>
> On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > For the past couple weeks, I've been trying to figure out why
> > approximately 900+ LLDB tests have been failing for me on my local
> > Windows builds.  Bisect turned up nothing--the "good" version that was
> > working for me no longer works.  Since nobody else seems to be seeing
> > these failures, I suspect it's something environmental.
> >
> > There are three categories of errors.  I'm currently focused on
> > failures that look like this:
> >
> > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py (732
> > of 2180)
> >  TEST 'lldb-api ::
> > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > 
> > Script:
> > --
> > C:/Program Files/Python38/python.exe
> > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > -u CFLAGS --enable-crash-dialog --env
> > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > D:/src/llvm/build/ninja_dbg/lldb-test-traces --lldb-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> lldb\lldb-api
> > --clang-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> clang\lldb-api
> > --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> > D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> > D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> > D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> > D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> > D:/src/llvm/build/ninja_dbg/./lib
> > D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> > TestUnicodeString.py
> > --
> > Exit Code: 1
> >
> > Command Output (stdout):
> > --
> > lldb version 12.0.0 (https://github.com/llvm/llvm-project.git
> >  revision
> > 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
> >clang revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> >llvm revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> >
> > --
> > Command Output (stderr):
> > --
> > Traceback (most recent call last):
> >File
> > "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> > line 35, in 
> >  import _lldb
> > ModuleNotFoundError: No module named '_lldb'
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >File "D:/src/llvm/llvm-project/lldb\test\API\dotest.py", line 7,
> > in 
> >  lldbsuite.test.run_suite()
> >File
> > "D:\src\llvm\llvm-
> project\lldb\packages\Python\lldbsuite\test\dotest.py",
> > line 874, in run_suite
> >  import lldb
> >File
> > "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> > line 38, in 
> >  from . import _lldb
> > ImportError: cannot import name '_lldb' from partially initialized
> > module 'lldb' (most likely due to a circular import)
> > (D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py)
> >
> >
> > It looks like the code in question is generated by Swig (so perhaps it
> > depends on the version of Swig?).  The relevant bit seems to be:
> >
> > try:
> >  # Try an absolute import first.  If we're being loaded from lldb,
> >  # _lldb should be a built-in module.
> >  import _lldb
> > except ImportError:
> >  # Relative import should work if we are being loaded by Python.
> > from . import _lldb
> >
> >
> > I don't have much background in Python modules or how Swig produces
> > the bindings.  It seems suspicious to me that both import attempts are
> > failing (and that we need two).
>
> The reason behind the two imports is that lldb+python have two ways of
> loading each other, depending on who is "on top".
>
> If you're starting with a c++ program (e.g. lldb driver), then the (lib)lldb 
> library
> will be loaded

[lldb-dev] [Bug 20476] Breakpoint on malloc() fails on FreeBSD stable/10

2020-11-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=20476

ema...@freebsd.org changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #3 from ema...@freebsd.org ---
Working on FreeBSD 13-CURRENT desktop now, unsure what the issue was

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 19011] test_with_dwarf (TestFormatters.ExprFormattersTestCase) fails on FreeBSD w/ system clang 3.4 -- constructor missing

2020-11-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=19011

ema...@freebsd.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 17231] test causes assertion failure on FreeBSD in ASTContext::getASTRecordLayout w/ DWARF from clang 3.3

2020-11-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=17231

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from ema...@freebsd.org ---
Unsure if this issue is still present but Clang 3.3 is long irrelevant

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 17214] inline stepping test fails on FreeBSD (intermittent failure)

2020-11-04 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=17214

ema...@freebsd.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #8 from ema...@freebsd.org ---
It looks like test_with_dwarf_and_python_api is now test_with_python_api_dwarf.

With D90757 applied `bin/lldb-dotest -p TestInlineStepping -f
test_with_python_api_dwarf` passes consistently for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev