[lldb-dev] [Bug 42514] lldb fails to configure when signing adhoc

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=42514

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |dav...@freebsd.org

-- 
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 42514] New: lldb fails to configure when signing adhoc

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=42514

Bug ID: 42514
   Summary: lldb fails to configure when signing adhoc
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jerem...@apple.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

In MacPorts, we build lldb using -DLLDB_CODESIGN_IDENTITY=- and have our users
sign it themselves after it is installed.

With the update to r365158, lldb is failing to configure with:

-- lldb debugserver:
/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_macports-ports_lang_llvm-devel/lldb-devel/work/build/./bin/debugserver
CMake Error at tools/lldb/tools/debugserver/source/CMakeLists.txt:155
(message):
  Certificate for debugserver not found.  Run scripts/macos-setup-codesign.sh
  or use the system debugserver passing -DLLDB_USE_SYSTEM_DEBUGSERVER=ON to
  CMake

This regressed in:

commit cb1c23cd40cea52c0816004dfa4fe1f81ce93deb
Author: Davide Italiano 
Date:   Tue Jun 25 17:13:24 2019 +

[CMake] Check that a certificate for lldb is present at build time.

Reviewers: JDevlieghere, sgraenitz, aprantl, friss

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D63745

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@364334
91177308-0d34-0410-b5e6-96231b3b80d8


The check added there needs to take adhoc signing into consideration.

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

Re: [lldb-dev] [RFC] Removing lldb-mi

[Raphael “Teemperor” Isemann via lldb-dev]

I just went forward with this and made a quick test repo with an out-of-tree 
lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi  
This seems to work fine with the exception of the python tests which require 
LLDB’s python code for testing which isn’t installed alongside LLDB. I guess we 
will have to see if we copy the related test code there or we just rewrite the 
test suite (which is anyway broken). On the upside, we can now just use Travis 
for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.

I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream 
time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi for users. 
Given how simple lldb-mi is, this seems like a reasonable timeframe.

- Raphael


> On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev 
>  wrote:
> 
> 
> 
> On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> We're using it with Eclipse and Eclipse based product, so I'd like to keep as 
> well! :-)...
> 
> Zdenek
> 
> 
> I do understand that there's desire from people to keep this around (from an 
> user perspective), but I guess this fundamentally misses Jonas' original mail 
> point.
> lldb-mi has been unmaintained for a long time (at least the past two years 
> from what I can tell), and we tried to use it in emacs without success.
> It has never been a priority for many of the parties putting effort in lldb 
> and I'm under the impression the situation won't change in the foreseeable 
> future.
> Unless somebody steps up as maintainer I don't think there's a lot of future 
> for the tool. 
> Maybe a good compromise would be that of having lldb-mi living in a separate 
> repo somewhere on GitHub, as it only uses the SBAPI, which is public and set 
> in stone?
> 
> --
> Davide
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

[Guilherme Andrade via lldb-dev]

I have two breakpoint inside methods that are called every frame (C++
project using Unreal), and every time one of them is reached, I evaluate
one expression (I'm being able to reproduce this using an undefined name,
say "undefinedVariable"). After a few iterations (usually tens), the time
it takes for LLDB to say that name doesn't exist increases, despite being
the same expression, at the same breakpoint and the call stack remaining
unchanged.

I've noticed that the number of lexical Decl queries and imports conducted
by Clang reported in 'Local metrics' increase.

They go from:
Number of visible Decl queries by name : 29
Number of lexical Decl queries: 9
Number of imports initiated by LLDB   : 15
Number of imports conducted by Clang  : 827
Number of Decls completed: 5
Number of records laid out  : 2

To:
Number of visible Decl queries by name : 29
Number of lexical Decl queries: 14
Number of imports initiated by LLDB   : 15
Number of imports conducted by Clang  : 1342
Number of Decls completed: 5
Number of records laid out  : 2

Also, the number of SymbolFileDWARF operations in the logs jumps from 366
to 406.

So, I've got two questions. 1) Is it safe to say that those extra imports
and Decl queries are responsible for the performance loss? 2) Why do they
happen?

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

Re: [lldb-dev] [RFC] Removing lldb-mi

[Davide Italiano via lldb-dev]

On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We're using it with Eclipse and Eclipse based product, so I'd like to keep
> as well! :-)...
>
> Zdenek
>

I do understand that there's desire from people to keep this around (from
an user perspective), but I guess this fundamentally misses Jonas' original
mail point.
lldb-mi has been unmaintained for a long time (at least the past two years
from what I can tell), and we tried to use it in emacs without success.
It has never been a priority for many of the parties putting effort in lldb
and I'm under the impression the situation won't change in the foreseeable
future.
Unless somebody steps up as maintainer I don't think there's a lot of
future for the tool.
Maybe a good compromise would be that of having lldb-mi living in a
separate repo somewhere on GitHub, as it only uses the SBAPI, which is
public and set in stone?

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

Re: [lldb-dev] [RFC] Removing lldb-mi

[Zdenek Prikryl via lldb-dev]

We're using it with Eclipse and Eclipse based product, so I'd like to 
keep as well! :-)...


Zdenek

On 7/2/19 12:21 AM, Ted Woodward via lldb-dev wrote:


We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d 
really like to keep it! 


Ted

*From:* lldb-dev  *On Behalf Of 
*Jonas Devlieghere via lldb-dev

*Sent:* Monday, July 1, 2019 5:09 PM
*To:* LLDB 
*Subject:* [EXT] [lldb-dev] [RFC] Removing lldb-mi

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,

Jonas


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


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