[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D122974#3481269 , @llunak wrote:

> In D122974#3480686 , @dblaikie 
> wrote:
>
>> In D122974#3424654 , @JDevlieghere 
>> wrote:
>>
>>> 
>
> ...
>
>>>   struct HashedStringRef {
>>> const llvm::StringRef str;
>>> const unsigned full_hash;
>>> const uint8_t hash; 
>>> HashedStringRef(llvm::StringRef s) : str(s), full_hash(djbHash(str)), 
>>> hash(hash(str)) {}
>>>   }
>
> ...
>
>> The external code shouldn't be able to create their own (ctor 
>> private/protected, etc) - the only way to get one is to call `StringMap` to 
>> produce one.
>
> But what if I don't want StringMap to compute the hash at all? There's still 
> that 10-15% of CPU time spent in djbHash() when debug info uses exactly[*] 
> that (and LLDB's index cache could be modified to store it). Which means it 
> can be useful for StringMap to allow accepting precomputed hash, and then 
> what purpose will that HashedStringRef have?

I think that David's point was that you would use a (probably static) StringMap 
method to produce the hash object, and then you use the hash object to select 
the correct map, and also to insert the key in the map. Something like:

  auto hash_obj = MyStringMap::Hash(key);
  MyStringMap &map = maps[hash_obj.one_char_hash];
  map.insert(has_obj, key, value);

That should only produce one hash computation, right?

> (*) Well, not exactly, the seed is different. Doesn't seem an impossible 
> problem to solve though.

I think that's because it's trying to produce a value that is not correlated to 
the value used inside the individual objects (so that you don't overload some 
buckets of the maps while keeping others empty). However, there are other ways 
to achieve that. Since StringMap is always using a power of two for the number 
of buckets, I think it would be sufficient to use an odd number of StringMap 
instances (say 255). Using the modulo operation to select the StringMap should 
select spread out the complete hashes evenly among to individual maps.

And it would mean that the StringMap does not have to concern itself with the 
one-char hashes (which definitely seems like a layering violation).

>> (these functions could/should probably still then assert that the hash is 
>> correct in case of that underlying mutation - though someone could argue 
>> that's overkill and I'd be open to having that discussion).
>
> I'd prefer to have that discussion. If your argument is perfection, then 
> let's do the full monty.

I guess we could put those checks under `#ifdef EXPENSIVE_CHECKS` (?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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


[Lldb-commits] [PATCH] D123954: [lldb] Add setting for max depth of value object printing (NFC)

2022-04-29 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett accepted this revision.
DavidSpickett added a comment.

All my comments were addressed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123954

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


[Lldb-commits] [PATCH] D124601: [lldb] Use shutil.which instead of distutils find_executable

2022-04-29 Thread David Spickett via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG14869bd2dfab: [lldb] Use shutil.which instead of distutils 
find_executable (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124601

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/Shell/lit.cfg.py


Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -12,7 +12,6 @@
 from lit.llvm import llvm_config
 from lit.llvm.subst import FindTool
 from lit.llvm.subst import ToolSubst
-from distutils.spawn import find_executable
 
 site.addsitedir(os.path.dirname(__file__))
 from helper import toolchain
@@ -121,7 +120,7 @@
 if config.lldb_enable_lzma:
 config.available_features.add('lzma')
 
-if find_executable('xz') != None:
+if shutil.which('xz') != None:
 config.available_features.add('xz')
 
 if config.lldb_system_debugserver:
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -49,7 +49,6 @@
 import sys
 import time
 import traceback
-import distutils.spawn
 
 # Third-party modules
 import unittest2
@@ -1568,7 +1567,7 @@
 
 # Tries to find clang at the same folder as the lldb
 lldb_dir = os.path.dirname(lldbtest_config.lldbExec)
-path = distutils.spawn.find_executable("clang", lldb_dir)
+path = shutil.which("clang", path=lldb_dir)
 if path is not None:
 return path
 


Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -12,7 +12,6 @@
 from lit.llvm import llvm_config
 from lit.llvm.subst import FindTool
 from lit.llvm.subst import ToolSubst
-from distutils.spawn import find_executable
 
 site.addsitedir(os.path.dirname(__file__))
 from helper import toolchain
@@ -121,7 +120,7 @@
 if config.lldb_enable_lzma:
 config.available_features.add('lzma')
 
-if find_executable('xz') != None:
+if shutil.which('xz') != None:
 config.available_features.add('xz')
 
 if config.lldb_system_debugserver:
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -49,7 +49,6 @@
 import sys
 import time
 import traceback
-import distutils.spawn
 
 # Third-party modules
 import unittest2
@@ -1568,7 +1567,7 @@
 
 # Tries to find clang at the same folder as the lldb
 lldb_dir = os.path.dirname(lldbtest_config.lldbExec)
-path = distutils.spawn.find_executable("clang", lldb_dir)
+path = shutil.which("clang", path=lldb_dir)
 if path is not None:
 return path
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 14869bd - [lldb] Use shutil.which instead of distutils find_executable

2022-04-29 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2022-04-29T08:41:34Z
New Revision: 14869bd2dfabb7a808e57e17dd45eef7665dd737

URL: 
https://github.com/llvm/llvm-project/commit/14869bd2dfabb7a808e57e17dd45eef7665dd737
DIFF: 
https://github.com/llvm/llvm-project/commit/14869bd2dfabb7a808e57e17dd45eef7665dd737.diff

LOG: [lldb] Use shutil.which instead of distutils find_executable

distutils is deprecated and shutil.which is the suggested
replacement for this function.

https://peps.python.org/pep-0632/#migration-advice
https://docs.python.org/3/library/shutil.html#shutil.which

It was added in Python3.3 but given that we're already using
shutil.which elsewhere I think this is ok/no worse than before.

We do have our own find_executable in lldb/test/Shell/helper/build.py
but I'd rather leave that as is for now. Also we have our own versions
of which() but again, a change for another time.

This work is part of #54337.

Reviewed By: JDevlieghere

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/test/Shell/lit.cfg.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 6a8c5bf74bc06..e1c8373eb29a4 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -49,7 +49,6 @@
 import sys
 import time
 import traceback
-import distutils.spawn
 
 # Third-party modules
 import unittest2
@@ -1568,7 +1567,7 @@ def findBuiltClang(self):
 
 # Tries to find clang at the same folder as the lldb
 lldb_dir = os.path.dirname(lldbtest_config.lldbExec)
-path = distutils.spawn.find_executable("clang", lldb_dir)
+path = shutil.which("clang", path=lldb_dir)
 if path is not None:
 return path
 

diff  --git a/lldb/test/Shell/lit.cfg.py b/lldb/test/Shell/lit.cfg.py
index ccff49194319b..b1e8957e63ed2 100644
--- a/lldb/test/Shell/lit.cfg.py
+++ b/lldb/test/Shell/lit.cfg.py
@@ -12,7 +12,6 @@
 from lit.llvm import llvm_config
 from lit.llvm.subst import FindTool
 from lit.llvm.subst import ToolSubst
-from distutils.spawn import find_executable
 
 site.addsitedir(os.path.dirname(__file__))
 from helper import toolchain
@@ -121,7 +120,7 @@ def calculate_arch_features(arch_string):
 if config.lldb_enable_lzma:
 config.available_features.add('lzma')
 
-if find_executable('xz') != None:
+if shutil.which('xz') != None:
 config.available_features.add('xz')
 
 if config.lldb_system_debugserver:



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


[Lldb-commits] [PATCH] D124604: [lldb] Use shutil.which in Shell tests find_executable

2022-04-29 Thread David Spickett via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG713752610edd: [lldb] Use shutil.which in Shell tests 
find_executable (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124604

Files:
  lldb/test/Shell/helper/build.py


Index: lldb/test/Shell/helper/build.py
===
--- lldb/test/Shell/helper/build.py
+++ lldb/test/Shell/helper/build.py
@@ -4,6 +4,7 @@
 
 import argparse
 import os
+import shutil
 import signal
 import subprocess
 import sys
@@ -170,16 +171,14 @@
 print('{0} = {1}'.format(e, formatted_value))
 
 def find_executable(binary_name, search_paths):
-if sys.platform == 'win32':
-binary_name = binary_name + '.exe'
-
-search_paths = os.pathsep.join(search_paths)
-paths = search_paths + os.pathsep + os.environ.get('PATH', '')
-for path in paths.split(os.pathsep):
-p = os.path.join(path, binary_name)
-if os.path.exists(p) and not os.path.isdir(p):
-return os.path.normpath(p)
-return None
+# shutil.which will ignore PATH if given a path argument, we want to 
include it.
+search_paths.append(os.environ.get('PATH', ''))
+search_path = os.pathsep.join(search_paths)
+binary_path = shutil.which(binary_name, path=search_path)
+if binary_path is not None:
+# So for example, we get '/bin/gcc' instead of '/usr/../bin/gcc'.
+binary_path = os.path.normpath(binary_path)
+return binary_path
 
 def find_toolchain(compiler, tools_dir):
 if compiler == 'msvc':


Index: lldb/test/Shell/helper/build.py
===
--- lldb/test/Shell/helper/build.py
+++ lldb/test/Shell/helper/build.py
@@ -4,6 +4,7 @@
 
 import argparse
 import os
+import shutil
 import signal
 import subprocess
 import sys
@@ -170,16 +171,14 @@
 print('{0} = {1}'.format(e, formatted_value))
 
 def find_executable(binary_name, search_paths):
-if sys.platform == 'win32':
-binary_name = binary_name + '.exe'
-
-search_paths = os.pathsep.join(search_paths)
-paths = search_paths + os.pathsep + os.environ.get('PATH', '')
-for path in paths.split(os.pathsep):
-p = os.path.join(path, binary_name)
-if os.path.exists(p) and not os.path.isdir(p):
-return os.path.normpath(p)
-return None
+# shutil.which will ignore PATH if given a path argument, we want to include it.
+search_paths.append(os.environ.get('PATH', ''))
+search_path = os.pathsep.join(search_paths)
+binary_path = shutil.which(binary_name, path=search_path)
+if binary_path is not None:
+# So for example, we get '/bin/gcc' instead of '/usr/../bin/gcc'.
+binary_path = os.path.normpath(binary_path)
+return binary_path
 
 def find_toolchain(compiler, tools_dir):
 if compiler == 'msvc':
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 7137526 - [lldb] Use shutil.which in Shell tests find_executable

2022-04-29 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2022-04-29T10:01:26Z
New Revision: 713752610edd3d8766f56e2704bb7241434cd15b

URL: 
https://github.com/llvm/llvm-project/commit/713752610edd3d8766f56e2704bb7241434cd15b
DIFF: 
https://github.com/llvm/llvm-project/commit/713752610edd3d8766f56e2704bb7241434cd15b.diff

LOG: [lldb] Use shutil.which in Shell tests find_executable

In build.py we have our own find_executable that looks
a lot like the distutils one that I switched to shutil.which.

This find_executable isn't quite the same as shutil.which
so I've refactored it to call that in the correct way.

Note that the path passed to shutil.which is in the form that
PATH would be, meaning separators are allowed.
```
>>> shutil.which("gcc", path="/home/david.spickett:/bin")
'/bin/gcc'
```

We just need to make sure it doesn't ignore the existing PATH
and normalise the result if it does find the binary.

The .exe extension is automatically added to the binary name
if we are on Windows.

Depends on D124601

Reviewed By: JDevlieghere

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

Added: 


Modified: 
lldb/test/Shell/helper/build.py

Removed: 




diff  --git a/lldb/test/Shell/helper/build.py b/lldb/test/Shell/helper/build.py
index 005f12bc09cf..97d790661d5a 100755
--- a/lldb/test/Shell/helper/build.py
+++ b/lldb/test/Shell/helper/build.py
@@ -4,6 +4,7 @@
 
 import argparse
 import os
+import shutil
 import signal
 import subprocess
 import sys
@@ -170,16 +171,14 @@ def print_environment(env):
 print('{0} = {1}'.format(e, formatted_value))
 
 def find_executable(binary_name, search_paths):
-if sys.platform == 'win32':
-binary_name = binary_name + '.exe'
-
-search_paths = os.pathsep.join(search_paths)
-paths = search_paths + os.pathsep + os.environ.get('PATH', '')
-for path in paths.split(os.pathsep):
-p = os.path.join(path, binary_name)
-if os.path.exists(p) and not os.path.isdir(p):
-return os.path.normpath(p)
-return None
+# shutil.which will ignore PATH if given a path argument, we want to 
include it.
+search_paths.append(os.environ.get('PATH', ''))
+search_path = os.pathsep.join(search_paths)
+binary_path = shutil.which(binary_name, path=search_path)
+if binary_path is not None:
+# So for example, we get '/bin/gcc' instead of '/usr/../bin/gcc'.
+binary_path = os.path.normpath(binary_path)
+return binary_path
 
 def find_toolchain(compiler, tools_dir):
 if compiler == 'msvc':



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


[Lldb-commits] [lldb] d9247cc - Revert "[lldb] Use shutil.which in Shell tests find_executable"

2022-04-29 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2022-04-29T11:02:59Z
New Revision: d9247cc84825539d346c74eb1379c6cb948d3a71

URL: 
https://github.com/llvm/llvm-project/commit/d9247cc84825539d346c74eb1379c6cb948d3a71
DIFF: 
https://github.com/llvm/llvm-project/commit/d9247cc84825539d346c74eb1379c6cb948d3a71.diff

LOG: Revert "[lldb] Use shutil.which in Shell tests find_executable"

This reverts commit 713752610edd3d8766f56e2704bb7241434cd15b.

Some test output needs updating for Windows builders:
https://lab.llvm.org/buildbot/#/builders/83/builds/18356

Added: 


Modified: 
lldb/test/Shell/helper/build.py

Removed: 




diff  --git a/lldb/test/Shell/helper/build.py b/lldb/test/Shell/helper/build.py
index 97d790661d5a..005f12bc09cf 100755
--- a/lldb/test/Shell/helper/build.py
+++ b/lldb/test/Shell/helper/build.py
@@ -4,7 +4,6 @@
 
 import argparse
 import os
-import shutil
 import signal
 import subprocess
 import sys
@@ -171,14 +170,16 @@ def print_environment(env):
 print('{0} = {1}'.format(e, formatted_value))
 
 def find_executable(binary_name, search_paths):
-# shutil.which will ignore PATH if given a path argument, we want to 
include it.
-search_paths.append(os.environ.get('PATH', ''))
-search_path = os.pathsep.join(search_paths)
-binary_path = shutil.which(binary_name, path=search_path)
-if binary_path is not None:
-# So for example, we get '/bin/gcc' instead of '/usr/../bin/gcc'.
-binary_path = os.path.normpath(binary_path)
-return binary_path
+if sys.platform == 'win32':
+binary_name = binary_name + '.exe'
+
+search_paths = os.pathsep.join(search_paths)
+paths = search_paths + os.pathsep + os.environ.get('PATH', '')
+for path in paths.split(os.pathsep):
+p = os.path.join(path, binary_name)
+if os.path.exists(p) and not os.path.isdir(p):
+return os.path.normpath(p)
+return None
 
 def find_toolchain(compiler, tools_dir):
 if compiler == 'msvc':



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


[Lldb-commits] [lldb] cacaa44 - Reland "[lldb] Use shutil.which in Shell tests find_executable"

2022-04-29 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2022-04-29T11:25:09Z
New Revision: cacaa445c3a3a2551a6e2aef51414e47def9cc06

URL: 
https://github.com/llvm/llvm-project/commit/cacaa445c3a3a2551a6e2aef51414e47def9cc06
DIFF: 
https://github.com/llvm/llvm-project/commit/cacaa445c3a3a2551a6e2aef51414e47def9cc06.diff

LOG: Reland "[lldb] Use shutil.which in Shell tests find_executable"

This reverts commit d9247cc84825539d346c74eb1379c6cb948d3a71.

With the Windows tests updated to expect .EXE suffixes. This changed
because shutil.which uses PATHEXT which will contain, amongst others,
"EXE".

Also I noticed the "." in ".exe" was the wildcard dot not literal
dot so I've escaped those.

Added: 


Modified: 
lldb/test/Shell/BuildScript/toolchain-clang-cl.test
lldb/test/Shell/BuildScript/toolchain-clang.test
lldb/test/Shell/BuildScript/toolchain-msvc.test
lldb/test/Shell/helper/build.py

Removed: 




diff  --git a/lldb/test/Shell/BuildScript/toolchain-clang-cl.test 
b/lldb/test/Shell/BuildScript/toolchain-clang-cl.test
index cc219aca158f9..8c9ea9fddb8a5 100644
--- a/lldb/test/Shell/BuildScript/toolchain-clang-cl.test
+++ b/lldb/test/Shell/BuildScript/toolchain-clang-cl.test
@@ -23,9 +23,9 @@ CHECK-32: Cleaning 
{{.*}}toolchain-clang-cl.test.tmp{{.}}foo.exe-foobar.obj
 CHECK-32: Cleaning {{.*}}toolchain-clang-cl.test.tmp{{.}}foo.pdb
 CHECK-32: Cleaning {{.*}}toolchain-clang-cl.test.tmp{{.}}foo.exe
 CHECK-32: compiling foobar.c -> foo.exe-foobar.obj
-CHECK-32: {{.*}}clang-cl{{(.exe)?}} -m32
+CHECK-32: {{.*}}clang-cl{{(\.EXE)?}} -m32
 CHECK-32: linking foo.exe-foobar.obj -> foo.exe
-CHECK-32: {{.*}}lld-link
+CHECK-32: {{.*}}lld-link{{(\.EXE)?}}
 
 CHECK-64: Script Arguments:
 CHECK-64:   Arch: 64
@@ -44,6 +44,6 @@ CHECK-64: Cleaning 
{{.*}}toolchain-clang-cl.test.tmp{{.}}foo.exe-foobar.obj
 CHECK-64: Cleaning {{.*}}toolchain-clang-cl.test.tmp{{.}}foo.pdb
 CHECK-64: Cleaning {{.*}}toolchain-clang-cl.test.tmp{{.}}foo.exe
 CHECK-64: compiling foobar.c -> foo.exe-foobar.obj
-CHECK-64: {{.*}}clang-cl{{(.exe)?}} -m64
+CHECK-64: {{.*}}clang-cl{{(\.EXE)?}} -m64
 CHECK-64: linking foo.exe-foobar.obj -> foo.exe
-CHECK-64: {{.*}}lld-link{{(.exe)?}}
+CHECK-64: {{.*}}lld-link{{(\.EXE)?}}

diff  --git a/lldb/test/Shell/BuildScript/toolchain-clang.test 
b/lldb/test/Shell/BuildScript/toolchain-clang.test
index eb2dbd543548c..1eaf7064065d6 100644
--- a/lldb/test/Shell/BuildScript/toolchain-clang.test
+++ b/lldb/test/Shell/BuildScript/toolchain-clang.test
@@ -7,8 +7,8 @@ RUN:| FileCheck --check-prefix=CHECK 
--check-prefix=CHECK-64 %s
 CHECK: Cleaning {{.*}}toolchain-clang.test.tmp{{.}}foo.exe-foobar.o
 CHECK: Cleaning {{.*}}toolchain-clang.test.tmp{{.}}foo.exe
 CHECK: compiling foobar.c -> foo.exe-foobar.o
-CHECK-32: {{.*}}clang++{{(.exe)?}} -m32 -g -O0 -c -o {{.*}}foo.exe-foobar.o 
{{.*}}foobar.c
-CHECK-64: {{.*}}clang++{{(.exe)?}} -m64 -g -O0 -c -o {{.*}}foo.exe-foobar.o 
{{.*}}foobar.c
+CHECK-32: {{.*}}clang++{{(\.EXE)?}} -m32 -g -O0 -c -o {{.*}}foo.exe-foobar.o 
{{.*}}foobar.c
+CHECK-64: {{.*}}clang++{{(\.EXE)?}} -m64 -g -O0 -c -o {{.*}}foo.exe-foobar.o 
{{.*}}foobar.c
 CHECK: linking foo.exe-foobar.o -> foo.exe
-CHECK-32: {{.*}}clang++{{(.exe)?}} -m32 {{(-L.* )?(-Wl,-rpath,.* )?}}-o 
{{.*}}foo.exe {{.*}}foo.exe-foobar.o
-CHECK-64: {{.*}}clang++{{(.exe)?}} -m64 {{(-L.* )?(-Wl,-rpath,.* )?}}-o 
{{.*}}foo.exe {{.*}}foo.exe-foobar.o
+CHECK-32: {{.*}}clang++{{(\.EXE)?}} -m32 {{(-L.* )?(-Wl,-rpath,.* )?}}-o 
{{.*}}foo.exe {{.*}}foo.exe-foobar.o
+CHECK-64: {{.*}}clang++{{(\.EXE)?}} -m64 {{(-L.* )?(-Wl,-rpath,.* )?}}-o 
{{.*}}foo.exe {{.*}}foo.exe-foobar.o

diff  --git a/lldb/test/Shell/BuildScript/toolchain-msvc.test 
b/lldb/test/Shell/BuildScript/toolchain-msvc.test
index 0ffd44489729f..6c0d3789869a6 100644
--- a/lldb/test/Shell/BuildScript/toolchain-msvc.test
+++ b/lldb/test/Shell/BuildScript/toolchain-msvc.test
@@ -23,9 +23,9 @@ RUN:| FileCheck --check-prefix=64BIT %s
 32BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.pdb
 32BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.exe
 32BIT: compiling foobar.c -> foo.exe-foobar.obj
-32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\cl.exe
+32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\cl.EXE
 32BIT: linking foo.exe-foobar.obj -> foo.exe
-32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\link.exe
+32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\link.EXE
 32BIT:   Env
 32BIT: LIB = {{.*}}\ATLMFC\lib\{{(x86|arm)}}
 32BIT:   {{.*}}\lib\{{(x86|arm)}}
@@ -51,9 +51,9 @@ RUN:| FileCheck --check-prefix=64BIT %s
 64BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.pdb
 64BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.exe
 64BIT: compiling foobar.c -> foo.exe-foobar.obj
-64BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\cl.exe
+64BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\cl.EXE
 

[Lldb-commits] [lldb] f8463da - [lldb] Allow EXE or exe in toolchain-msvc.test

2022-04-29 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2022-04-29T12:22:33Z
New Revision: f8463da4a329b839cfd01d7f80ae72e18f3c061e

URL: 
https://github.com/llvm/llvm-project/commit/f8463da4a329b839cfd01d7f80ae72e18f3c061e
DIFF: 
https://github.com/llvm/llvm-project/commit/f8463da4a329b839cfd01d7f80ae72e18f3c061e.diff

LOG: [lldb] Allow EXE or exe in toolchain-msvc.test

I suspect that one of link or cl is found by shutil.which
and one isn't, hence the case difference. It doesn't really
matter for what the test is looking for.

Added: 


Modified: 
lldb/test/Shell/BuildScript/toolchain-msvc.test

Removed: 




diff  --git a/lldb/test/Shell/BuildScript/toolchain-msvc.test 
b/lldb/test/Shell/BuildScript/toolchain-msvc.test
index 6c0d3789869a..dce87d5aee2a 100644
--- a/lldb/test/Shell/BuildScript/toolchain-msvc.test
+++ b/lldb/test/Shell/BuildScript/toolchain-msvc.test
@@ -23,9 +23,9 @@ RUN:| FileCheck --check-prefix=64BIT %s
 32BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.pdb
 32BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.exe
 32BIT: compiling foobar.c -> foo.exe-foobar.obj
-32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\cl.EXE
+32BIT:   Command Line: 
{{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\cl.{{EXE|exe}}
 32BIT: linking foo.exe-foobar.obj -> foo.exe
-32BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\link.EXE
+32BIT:   Command Line: 
{{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x86|arm)}}\link.{{EXE|exe}}
 32BIT:   Env
 32BIT: LIB = {{.*}}\ATLMFC\lib\{{(x86|arm)}}
 32BIT:   {{.*}}\lib\{{(x86|arm)}}
@@ -51,9 +51,9 @@ RUN:| FileCheck --check-prefix=64BIT %s
 64BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.pdb
 64BIT: Cleaning {{.*}}toolchain-msvc.test.tmp\foo.exe
 64BIT: compiling foobar.c -> foo.exe-foobar.obj
-64BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\cl.EXE
+64BIT:   Command Line: 
{{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\cl.{{EXE|exe}}
 64BIT: linking foo.exe-foobar.obj -> foo.exe
-64BIT:   Command Line: {{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\link.EXE
+64BIT:   Command Line: 
{{.*}}\{{[Hh]ost[Xx](64|86)}}\{{(x64|arm64)}}\link.{{EXE|exe}}
 64BIT:   Env
 64BIT: LIB = {{.*}}\ATLMFC\lib\{{(x64|arm64)}}
 64BIT:   {{.*}}\lib\{{(x64|arm64)}}



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


[Lldb-commits] [PATCH] D124670:

2022-04-29 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett created this revision.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

TODO: This would require packaging (https://github.com/pypa/packaging)

  to be added as a third party module, it is not part of the base python.

[lldb] Use packaging.version instead of distutils Strict/LooseVersion

distutils is deprecated (https://peps.python.org/pep-0632/) and
packaging is the recommended replacement.

Although LegacyVersion is itself deprecated within packaging,
we have our own copy of the package so that's not a risk until it
needs updating.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124670

Files:
  lldb/packages/Python/lldbsuite/test/decorators.py
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/tools/lldb-server/TestAppleSimulatorOSType.py
  lldb/test/Shell/helper/build.py

Index: lldb/test/Shell/helper/build.py
===
--- lldb/test/Shell/helper/build.py
+++ lldb/test/Shell/helper/build.py
@@ -351,8 +351,8 @@
 if not subdirs:
 return None
 
-from distutils.version import StrictVersion
-subdirs.sort(key=lambda x : StrictVersion(x))
+from packaging.version import Version
+subdirs.sort(key=lambda x : Version(x))
 
 if self.verbose:
 full_path = os.path.join(vcinstalldir, subdirs[-1])
@@ -417,9 +417,9 @@
 return (None, None)
 
 # Windows SDK version numbers consist of 4 dotted components, so we
-# have to use LooseVersion, as StrictVersion supports 3 or fewer.
-from distutils.version import LooseVersion
-sdk_versions.sort(key=lambda x : LooseVersion(x), reverse=True)
+# have to use LegacyVersion, as Version expects 3 or fewer.
+from packaging.version import LegacyVersion
+sdk_versions.sort(key=lambda x : LegacyVersion(x), reverse=True)
 option_value_name = 'OptionId.DesktopCPP' + self.msvc_arch_str
 for v in sdk_versions:
 try:
Index: lldb/test/API/tools/lldb-server/TestAppleSimulatorOSType.py
===
--- lldb/test/API/tools/lldb-server/TestAppleSimulatorOSType.py
+++ lldb/test/API/tools/lldb-server/TestAppleSimulatorOSType.py
@@ -54,8 +54,8 @@
 
 # Older versions of watchOS (<7.0) only support i386
 if platform_name == 'watchos':
-from distutils.version import LooseVersion
-if LooseVersion(vers) < LooseVersion("7.0"):
+from packaging.version import LegacyVersion
+if LegacyVersion(vers) < LegacyVersion("7.0"):
 arch = 'i386'
 
 triple = '-'.join([arch, 'apple', platform_name + vers, 'simulator'])
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -36,7 +36,6 @@
 
 # System modules
 import abc
-from distutils.version import LooseVersion
 from functools import wraps
 import gc
 import glob
@@ -51,6 +50,7 @@
 import traceback
 
 # Third-party modules
+from packaging.version import LegacyVersion
 import unittest2
 from six import add_metaclass
 from six import StringIO as SixStringIO
@@ -1354,13 +1354,13 @@
 return operator in ['>', '>=', '!', '!=', 'not']
 
 if operator == '>':
-return LooseVersion(test_compiler_version) > LooseVersion(version)
+return LegacyVersion(test_compiler_version) > LegacyVersion(version)
 if operator == '>=' or operator == '=>':
-return LooseVersion(test_compiler_version) >= LooseVersion(version)
+return LegacyVersion(test_compiler_version) >= LegacyVersion(version)
 if operator == '<':
-return LooseVersion(test_compiler_version) < LooseVersion(version)
+return LegacyVersion(test_compiler_version) < LegacyVersion(version)
 if operator == '<=' or operator == '=<':
-return LooseVersion(test_compiler_version) <= LooseVersion(version)
+return LegacyVersion(test_compiler_version) <= LegacyVersion(version)
 if operator == '!=' or operator == '!' or operator == 'not':
 return str(version) not in str(test_compiler_version)
 return str(version) in str(test_compiler_version)
Index: lldb/packages/Python/lldbsuite/test/decorators.py
===
--- lldb/packages/Python/lldbsuite/test/decorators.py
+++ lldb/packages/Python/lldbsuite/test/decorators.py
@@ -1,7 +1,6 @@
 from __future__ import absolute_import
 
 # System modules
-from distutils.version import LooseVersion
 from functools import wraps
 import ctypes
 import locale
@@ -13,6 +12,7 @

[Lldb-commits] [PATCH] D124670:

2022-04-29 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added a comment.

For https://github.com/llvm/llvm-project/issues/54337.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124670

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


[Lldb-commits] [PATCH] D124672: [lldb] Define LLDB_VERSION_PATCH correctly

2022-04-29 Thread Dimitry Andric via Phabricator via lldb-commits
dim created this revision.
dim added reviewers: JDevlieghere, labath.
Herald added a project: All.
dim requested review of this revision.
Herald added a project: LLDB.

In commit ccf1469a4cdb 
 lldb got 
its own generated Version.inc file, with
`LLDB_VERSION` macros. However, it used `LLDB_VERSION_PATCHLEVEL`
instead of the actually correct `LLDB_VERSION_PATCH`. Correct this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124672

Files:
  lldb/include/lldb/Version/Version.inc.in


Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"


Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Luboš Luňák via Phabricator via lldb-commits
llunak added a comment.

In D122974#3481852 , @labath wrote:

> In D122974#3481269 , @llunak wrote:
>
>> But what if I don't want StringMap to compute the hash at all? There's still 
>> that 10-15% of CPU time spent in djbHash() when debug info uses exactly[*] 
>> that (and LLDB's index cache could be modified to store it). Which means it 
>> can be useful for StringMap to allow accepting precomputed hash, and then 
>> what purpose will that HashedStringRef have?
>
> I think that David's point was that you would use a (probably static) 
> StringMap method to produce the hash object, and then you use the hash object 
> to select the correct map, and also to insert the key in the map. Something 
> like:

...

> That should only produce one hash computation, right?

Yes, it would, but that's not my point. If StringMap insists on computing the 
hash itself and doesn't allow outside code to provide it, then that prevents 
the possible LLDB optimization saving the remaing 10-15% startup CPU cost by 
not computing the hash at all. If StringMap allows that, then this 
HashedStringRef idea can be easily circumvented by passing the hash directly, 
so it seems rather pointless. And the relevant LLDB code from this change is so 
small that creating HashedStringRef just for that seems like an overkill.

>> (*) Well, not exactly, the seed is different. Doesn't seem an impossible 
>> problem to solve though.
>
> I think that's because it's trying to produce a value that is not correlated 
> to the value used inside the individual objects (so that you don't overload 
> some buckets of the maps while keeping others empty). However, there are 
> other ways to achieve that. Since StringMap is always using a power of two 
> for the number of buckets, I think it would be sufficient to use an odd 
> number of StringMap instances (say 255). Using the modulo operation to select 
> the StringMap should select spread out the complete hashes evenly among to 
> individual maps.

By different seed I meant that DWARF and StringMap use different seed for DJB 
hash. And that's only because LLVM code historically used the worse 0 seed and 
some tests rely on that (7b319df29bf4ebe690ca0c41761e46d8b0081293 
). But it 
seems that LLDB doesn't even read .debug_names entries into memory, so this 
having anything to do with DWARF debuginfo is actually moot, it'd only matter 
for LLDB index cache, which could use any hash it wants.

But you're possibly talking about something unrelated here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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


[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D122974#3482540 , @llunak wrote:

> In D122974#3481852 , @labath wrote:
>
>> In D122974#3481269 , @llunak wrote:
>>
>>> But what if I don't want StringMap to compute the hash at all? There's 
>>> still that 10-15% of CPU time spent in djbHash() when debug info uses 
>>> exactly[*] that (and LLDB's index cache could be modified to store it). 
>>> Which means it can be useful for StringMap to allow accepting precomputed 
>>> hash, and then what purpose will that HashedStringRef have?
>>
>> I think that David's point was that you would use a (probably static) 
>> StringMap method to produce the hash object, and then you use the hash 
>> object to select the correct map, and also to insert the key in the map. 
>> Something like:
>
> ...
>
>> That should only produce one hash computation, right?
>
> Yes, it would, but that's not my point. If StringMap insists on computing the 
> hash itself and doesn't allow outside code to provide it, then that prevents 
> the possible LLDB optimization saving the remaing 10-15% startup CPU cost by 
> not computing the hash at all. If StringMap allows that, then this 
> HashedStringRef idea can be easily circumvented by passing the hash directly, 
> so it seems rather pointless. And the relevant LLDB code from this change is 
> so small that creating HashedStringRef just for that seems like an overkill.

Interesting. I don't know if I missed this somewhere, but could explain what 
kind of a map operation can lldb perform without computing the hash at least 
once?

>>> (*) Well, not exactly, the seed is different. Doesn't seem an impossible 
>>> problem to solve though.
>>
>> I think that's because it's trying to produce a value that is not correlated 
>> to the value used inside the individual objects (so that you don't overload 
>> some buckets of the maps while keeping others empty). However, there are 
>> other ways to achieve that. Since StringMap is always using a power of two 
>> for the number of buckets, I think it would be sufficient to use an odd 
>> number of StringMap instances (say 255). Using the modulo operation to 
>> select the StringMap should select spread out the complete hashes evenly 
>> among to individual maps.
>
> By different seed I meant that DWARF and StringMap use different seed for DJB 
> hash. And that's only because LLVM code historically used the worse 0 seed 
> and some tests rely on that (7b319df29bf4ebe690ca0c41761e46d8b0081293 
> ). But 
> it seems that LLDB doesn't even read .debug_names entries into memory, so 
> this having anything to do with DWARF debuginfo is actually moot, it'd only 
> matter for LLDB index cache, which could use any hash it wants.
>
> But you're possibly talking about something unrelated here.

Yeah, I thought that the we used a different seed (or hash?) when computing the 
StringMap index -- I believe that was the case at some point, but I guess it 
was changed since then...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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


[Lldb-commits] [PATCH] D124673: [llvm][lldb] use FindLibEdit.cmake everywhere

2022-04-29 Thread Tobias Ribizel via Phabricator via lldb-commits
upsj created this revision.
upsj added reviewers: mgorny, MaskRay.
Herald added subscribers: StephenFan, hiraditya.
Herald added a project: All.
upsj requested review of this revision.
Herald added projects: LLDB, LLVM.
Herald added subscribers: llvm-commits, lldb-commits.

Currently, LLVM's LineEditor and LLDB both use libedit, but find them in 
different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of 
libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124673

Files:
  cmake/Modules/FindLibEdit.cmake
  lldb/cmake/modules/FindLibEdit.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  llvm/cmake/config-ix.cmake
  llvm/include/llvm/Config/config.h.cmake
  llvm/lib/LineEditor/CMakeLists.txt
  utils/bazel/llvm_configs/config.h.cmake

Index: utils/bazel/llvm_configs/config.h.cmake
===
--- utils/bazel/llvm_configs/config.h.cmake
+++ utils/bazel/llvm_configs/config.h.cmake
@@ -105,7 +105,7 @@
 #cmakedefine HAVE_ISATTY 1
 
 /* Define to 1 if you have the `edit' library (-ledit). */
-#cmakedefine HAVE_LIBEDIT ${HAVE_LIBEDIT}
+#cmakedefine HAVE_LIBEDIT ${LibEdit_FOUND}
 
 /* Define to 1 if you have the `pfm' library (-lpfm). */
 #cmakedefine HAVE_LIBPFM ${HAVE_LIBPFM}
Index: llvm/lib/LineEditor/CMakeLists.txt
===
--- llvm/lib/LineEditor/CMakeLists.txt
+++ llvm/lib/LineEditor/CMakeLists.txt
@@ -1,15 +1,14 @@
-if(HAVE_LIBEDIT)
-  set(link_libs edit)
-endif()
+# LibEdit is found in llvm/cmake/config-ix.cmake
 
 add_llvm_component_library(LLVMLineEditor
   LineEditor.cpp
 
   ADDITIONAL_HEADER_DIRS
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/LineEditor
+  ${LibEdit_INCLUDE_DIRS}
 
   LINK_LIBS
-  ${link_libs}
+  ${LibEdit_LIBRARIES}
 
   LINK_COMPONENTS
   Support
Index: llvm/include/llvm/Config/config.h.cmake
===
--- llvm/include/llvm/Config/config.h.cmake
+++ llvm/include/llvm/Config/config.h.cmake
@@ -105,7 +105,7 @@
 #cmakedefine HAVE_ISATTY 1
 
 /* Define to 1 if you have the `edit' library (-ledit). */
-#cmakedefine HAVE_LIBEDIT ${HAVE_LIBEDIT}
+#cmakedefine HAVE_LIBEDIT ${LibEdit_FOUND}
 
 /* Define to 1 if you have the `pfm' library (-lpfm). */
 #cmakedefine HAVE_LIBPFM ${HAVE_LIBPFM}
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -64,7 +64,6 @@
 check_symbol_exists(FE_INEXACT "fenv.h" HAVE_DECL_FE_INEXACT)
 
 check_include_file(mach/mach.h HAVE_MACH_MACH_H)
-check_include_file(histedit.h HAVE_HISTEDIT_H)
 check_include_file(CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H)
 if(APPLE)
   include(CheckCSourceCompiles)
@@ -184,10 +183,11 @@
   # Don't look for these libraries on Windows.
   if (NOT PURE_WINDOWS)
 # Skip libedit if using ASan as it contains memory leaks.
-if (LLVM_ENABLE_LIBEDIT AND HAVE_HISTEDIT_H AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
-  check_library_exists(edit el_init "" HAVE_LIBEDIT)
-else()
-  set(HAVE_LIBEDIT 0)
+if (LLVM_ENABLE_LIBEDIT)
+  if (LLVM_USE_SANITIZER MATCHES ".*Address.*")
+message(FATAL_ERROR "LLVM_ENABLE_LIBEDIT cannot be enabled with LLVM_USE_SANITIZER set to AddressSanitizer")
+  endif()
+  find_package(LibEdit REQUIRED)
 endif()
 if(LLVM_ENABLE_TERMINFO)
   if(LLVM_ENABLE_TERMINFO STREQUAL FORCE_ON)
Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -56,7 +56,9 @@
   message(STATUS "${description}: ${${variable}}")
 endmacro()
 
-add_optional_dependency(LLDB_ENABLE_LIBEDIT "Enable editline support in LLDB" LibEdit LibEdit_FOUND)
+if(LLVM_ENABLE_LIBEDIT)
+  find_package(LibEdit REQUIRED)
+endif()
 add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" CursesAndPanel CURSESANDPANEL_FOUND)
 add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in LLDB" LibLZMA LIBLZMA_FOUND)
 add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" LuaAndSwig LUAANDSWIG_FOUND)
Index: lldb/cmake/modules/FindLibEdit.cmake
===
--- /dev/null
+++ lldb/cmake/modules/FindLibEdit.cmake
@@ -1,64 +0,0 @@
-#.rst:
-# FindLibEdit
-# ---
-#
-# Find libedit library and headers
-#
-# The module defines the following variables:
-#
-# ::
-#
-#   LibEdit_FOUND  - true if libedit was found
-#   LibEdit_INCLUDE_DIRS   - include search path
-#   LibEdit_LIBRARIES  - libraries to link
-#   LibEdit_VERSION_STRING - version number
-
-if(LibEdit_INCLUDE_DIRS AND LibEdit_LIBRARIES)
-  set(LibEdit_FOUND TRUE)
-els

[Lldb-commits] [PATCH] D124672: [lldb] Define LLDB_VERSION_PATCH correctly

2022-04-29 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

Good catch. Seems like there's another reference to this in 
`llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn` but otherwise LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124672

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


[Lldb-commits] [PATCH] D124673: [llvm][lldb] use FindLibEdit.cmake everywhere

2022-04-29 Thread Tobias Ribizel via Phabricator via lldb-commits
upsj updated this revision to Diff 426068.
upsj added a comment.
Herald added a subscriber: JDevlieghere.

The previous setup didn't work for clang-query, so I added a CMake IMPORTED 
target for LibEdit and used it everywhere


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124673

Files:
  cmake/Modules/FindLibEdit.cmake
  lldb/cmake/modules/FindLibEdit.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/source/Core/CMakeLists.txt
  lldb/source/Host/CMakeLists.txt
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/lib/LineEditor/CMakeLists.txt
  llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
  utils/bazel/llvm_configs/config.h.cmake

Index: utils/bazel/llvm_configs/config.h.cmake
===
--- utils/bazel/llvm_configs/config.h.cmake
+++ utils/bazel/llvm_configs/config.h.cmake
@@ -105,7 +105,7 @@
 #cmakedefine HAVE_ISATTY 1
 
 /* Define to 1 if you have the `edit' library (-ledit). */
-#cmakedefine HAVE_LIBEDIT ${HAVE_LIBEDIT}
+#cmakedefine HAVE_LIBEDIT ${LibEdit_FOUND}
 
 /* Define to 1 if you have the `pfm' library (-lpfm). */
 #cmakedefine HAVE_LIBPFM ${HAVE_LIBPFM}
Index: llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
@@ -142,7 +142,7 @@
   #   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
   # endif()
   # if (LLDB_ENABLE_LIBEDIT)
-  #   list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  #   list(APPEND EXTRA_LIBS LibEdit::LibEdit)
   # endif()
   # if (LLDB_ENABLE_LZMA)
   #   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
Index: llvm/lib/LineEditor/CMakeLists.txt
===
--- llvm/lib/LineEditor/CMakeLists.txt
+++ llvm/lib/LineEditor/CMakeLists.txt
@@ -1,6 +1,4 @@
-if(HAVE_LIBEDIT)
-  set(link_libs edit)
-endif()
+# LibEdit is found in llvm/cmake/config-ix.cmake
 
 add_llvm_component_library(LLVMLineEditor
   LineEditor.cpp
@@ -9,7 +7,7 @@
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/LineEditor
 
   LINK_LIBS
-  ${link_libs}
+  LibEdit::LibEdit
 
   LINK_COMPONENTS
   Support
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -64,7 +64,6 @@
 check_symbol_exists(FE_INEXACT "fenv.h" HAVE_DECL_FE_INEXACT)
 
 check_include_file(mach/mach.h HAVE_MACH_MACH_H)
-check_include_file(histedit.h HAVE_HISTEDIT_H)
 check_include_file(CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H)
 if(APPLE)
   include(CheckCSourceCompiles)
@@ -184,10 +183,13 @@
   # Don't look for these libraries on Windows.
   if (NOT PURE_WINDOWS)
 # Skip libedit if using ASan as it contains memory leaks.
-if (LLVM_ENABLE_LIBEDIT AND HAVE_HISTEDIT_H AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
-  check_library_exists(edit el_init "" HAVE_LIBEDIT)
-else()
-  set(HAVE_LIBEDIT 0)
+if (LLVM_ENABLE_LIBEDIT)
+  if (LLVM_USE_SANITIZER MATCHES ".*Address.*")
+set(HAVE_LIBEDIT 0)
+  else()
+find_package(LibEdit REQUIRED)
+set(HAVE_LIBEDIT 1)
+  endif()
 endif()
 if(LLVM_ENABLE_TERMINFO)
   if(LLVM_ENABLE_TERMINFO STREQUAL FORCE_ON)
Index: lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
===
--- lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
+++ lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
@@ -10,7 +10,7 @@
 
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
 endif()
 
 add_lldb_library(lldbPluginScriptInterpreterPython PLUGIN
@@ -35,9 +35,3 @@
   LINK_COMPONENTS
 Support
   )
-
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbPluginScriptInterpreterPython PUBLIC
-${LibEdit_INCLUDE_DIRS}
-  )
-endif()
Index: lldb/source/Interpreter/CMakeLists.txt
===
--- lldb/source/Interpreter/CMakeLists.txt
+++ lldb/source/Interpreter/CMakeLists.txt
@@ -68,6 +68,3 @@
   LLDBInterpreterPropertiesGen
   LLDBInterpreterPropertiesEnumGen)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbInterpreter PRIVATE ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Host/CMakeLists.txt
===
--- lldb/source/Host/CMakeLists.txt
+++ lldb/source/Host/CMakeLists.txt
@@ -141,7 +141,7 @@
   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
 endif()
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND EXTRA_LIBS LibEdit::LibEdit)
 endif()
 if (LLDB_ENABLE_LZMA)
   list(APPEND EXTRA_LIBS ${L

[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Luboš Luňák via Phabricator via lldb-commits
llunak added a comment.

In D122974#3482556 , @labath wrote:

> Interesting. I don't know if I missed this somewhere, but could explain what 
> kind of a map operation can lldb perform without computing the hash at least 
> once?

All of them :). Computing is not the only way of obtaining the hash of a 
string. LLDB index cache (settings set symbols.enable-lldb-index-cache true) 
stores a big bunch of strings and when loading them back into ConstString the 
next time djbHash() is ~15% of total CPU LLDB startup time. That could be saved 
if the cache cached the hash values too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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


[Lldb-commits] [PATCH] D124673: [llvm][lldb] use FindLibEdit.cmake everywhere

2022-04-29 Thread Tobias Ribizel via Phabricator via lldb-commits
upsj updated this revision to Diff 426071.
upsj added a comment.

fix broken build without libedit, improve find module


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124673

Files:
  cmake/Modules/FindLibEdit.cmake
  lldb/cmake/modules/FindLibEdit.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/source/Core/CMakeLists.txt
  lldb/source/Host/CMakeLists.txt
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/lib/LineEditor/CMakeLists.txt
  llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
  utils/bazel/llvm_configs/config.h.cmake

Index: utils/bazel/llvm_configs/config.h.cmake
===
--- utils/bazel/llvm_configs/config.h.cmake
+++ utils/bazel/llvm_configs/config.h.cmake
@@ -105,7 +105,7 @@
 #cmakedefine HAVE_ISATTY 1
 
 /* Define to 1 if you have the `edit' library (-ledit). */
-#cmakedefine HAVE_LIBEDIT ${HAVE_LIBEDIT}
+#cmakedefine HAVE_LIBEDIT ${LibEdit_FOUND}
 
 /* Define to 1 if you have the `pfm' library (-lpfm). */
 #cmakedefine HAVE_LIBPFM ${HAVE_LIBPFM}
Index: llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
@@ -142,7 +142,7 @@
   #   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
   # endif()
   # if (LLDB_ENABLE_LIBEDIT)
-  #   list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  #   list(APPEND EXTRA_LIBS LibEdit::LibEdit)
   # endif()
   # if (LLDB_ENABLE_LZMA)
   #   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
Index: llvm/lib/LineEditor/CMakeLists.txt
===
--- llvm/lib/LineEditor/CMakeLists.txt
+++ llvm/lib/LineEditor/CMakeLists.txt
@@ -1,5 +1,5 @@
 if(HAVE_LIBEDIT)
-  set(link_libs edit)
+  set(link_libs LibEdit::LibEdit)
 endif()
 
 add_llvm_component_library(LLVMLineEditor
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -64,7 +64,6 @@
 check_symbol_exists(FE_INEXACT "fenv.h" HAVE_DECL_FE_INEXACT)
 
 check_include_file(mach/mach.h HAVE_MACH_MACH_H)
-check_include_file(histedit.h HAVE_HISTEDIT_H)
 check_include_file(CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H)
 if(APPLE)
   include(CheckCSourceCompiles)
@@ -184,10 +183,13 @@
   # Don't look for these libraries on Windows.
   if (NOT PURE_WINDOWS)
 # Skip libedit if using ASan as it contains memory leaks.
-if (LLVM_ENABLE_LIBEDIT AND HAVE_HISTEDIT_H AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
-  check_library_exists(edit el_init "" HAVE_LIBEDIT)
-else()
-  set(HAVE_LIBEDIT 0)
+if (LLVM_ENABLE_LIBEDIT)
+  if (LLVM_USE_SANITIZER MATCHES ".*Address.*")
+set(HAVE_LIBEDIT 0)
+  else()
+find_package(LibEdit REQUIRED)
+set(HAVE_LIBEDIT 1)
+  endif()
 endif()
 if(LLVM_ENABLE_TERMINFO)
   if(LLVM_ENABLE_TERMINFO STREQUAL FORCE_ON)
Index: lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
===
--- lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
+++ lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
@@ -10,7 +10,7 @@
 
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
 endif()
 
 add_lldb_library(lldbPluginScriptInterpreterPython PLUGIN
@@ -35,9 +35,3 @@
   LINK_COMPONENTS
 Support
   )
-
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbPluginScriptInterpreterPython PUBLIC
-${LibEdit_INCLUDE_DIRS}
-  )
-endif()
Index: lldb/source/Interpreter/CMakeLists.txt
===
--- lldb/source/Interpreter/CMakeLists.txt
+++ lldb/source/Interpreter/CMakeLists.txt
@@ -68,6 +68,3 @@
   LLDBInterpreterPropertiesGen
   LLDBInterpreterPropertiesEnumGen)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbInterpreter PRIVATE ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Host/CMakeLists.txt
===
--- lldb/source/Host/CMakeLists.txt
+++ lldb/source/Host/CMakeLists.txt
@@ -141,7 +141,7 @@
   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
 endif()
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND EXTRA_LIBS LibEdit::LibEdit)
 endif()
 if (LLDB_ENABLE_LZMA)
   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
@@ -151,7 +151,7 @@
 endif()
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
   if (LLVM_BUILD_STATIC)
 list(APPEND LLDB_SYSTEM_LIBS gpm)
   endif()
@@ -171,6 +171,3 @@

[Lldb-commits] [PATCH] D124673: [llvm][lldb] use FindLibEdit.cmake everywhere

2022-04-29 Thread Tobias Ribizel via Phabricator via lldb-commits
upsj updated this revision to Diff 426072.
upsj added a comment.

revert remaining unnecessary change from initial diff


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124673

Files:
  cmake/Modules/FindLibEdit.cmake
  lldb/cmake/modules/FindLibEdit.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/source/Core/CMakeLists.txt
  lldb/source/Host/CMakeLists.txt
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/lib/LineEditor/CMakeLists.txt
  llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn

Index: llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
@@ -142,7 +142,7 @@
   #   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
   # endif()
   # if (LLDB_ENABLE_LIBEDIT)
-  #   list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  #   list(APPEND EXTRA_LIBS LibEdit::LibEdit)
   # endif()
   # if (LLDB_ENABLE_LZMA)
   #   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
Index: llvm/lib/LineEditor/CMakeLists.txt
===
--- llvm/lib/LineEditor/CMakeLists.txt
+++ llvm/lib/LineEditor/CMakeLists.txt
@@ -1,5 +1,5 @@
 if(HAVE_LIBEDIT)
-  set(link_libs edit)
+  set(link_libs LibEdit::LibEdit)
 endif()
 
 add_llvm_component_library(LLVMLineEditor
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -64,7 +64,6 @@
 check_symbol_exists(FE_INEXACT "fenv.h" HAVE_DECL_FE_INEXACT)
 
 check_include_file(mach/mach.h HAVE_MACH_MACH_H)
-check_include_file(histedit.h HAVE_HISTEDIT_H)
 check_include_file(CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H)
 if(APPLE)
   include(CheckCSourceCompiles)
@@ -184,10 +183,13 @@
   # Don't look for these libraries on Windows.
   if (NOT PURE_WINDOWS)
 # Skip libedit if using ASan as it contains memory leaks.
-if (LLVM_ENABLE_LIBEDIT AND HAVE_HISTEDIT_H AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
-  check_library_exists(edit el_init "" HAVE_LIBEDIT)
-else()
-  set(HAVE_LIBEDIT 0)
+if (LLVM_ENABLE_LIBEDIT)
+  if (LLVM_USE_SANITIZER MATCHES ".*Address.*")
+set(HAVE_LIBEDIT 0)
+  else()
+find_package(LibEdit REQUIRED)
+set(HAVE_LIBEDIT 1)
+  endif()
 endif()
 if(LLVM_ENABLE_TERMINFO)
   if(LLVM_ENABLE_TERMINFO STREQUAL FORCE_ON)
Index: lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
===
--- lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
+++ lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
@@ -10,7 +10,7 @@
 
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
 endif()
 
 add_lldb_library(lldbPluginScriptInterpreterPython PLUGIN
@@ -35,9 +35,3 @@
   LINK_COMPONENTS
 Support
   )
-
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbPluginScriptInterpreterPython PUBLIC
-${LibEdit_INCLUDE_DIRS}
-  )
-endif()
Index: lldb/source/Interpreter/CMakeLists.txt
===
--- lldb/source/Interpreter/CMakeLists.txt
+++ lldb/source/Interpreter/CMakeLists.txt
@@ -68,6 +68,3 @@
   LLDBInterpreterPropertiesGen
   LLDBInterpreterPropertiesEnumGen)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbInterpreter PRIVATE ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Host/CMakeLists.txt
===
--- lldb/source/Host/CMakeLists.txt
+++ lldb/source/Host/CMakeLists.txt
@@ -141,7 +141,7 @@
   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
 endif()
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND EXTRA_LIBS LibEdit::LibEdit)
 endif()
 if (LLDB_ENABLE_LZMA)
   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
@@ -151,7 +151,7 @@
 endif()
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
   if (LLVM_BUILD_STATIC)
 list(APPEND LLDB_SYSTEM_LIBS gpm)
   endif()
@@ -171,6 +171,3 @@
 Support
   )
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbHost PUBLIC ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Core/CMakeLists.txt
===
--- lldb/source/Core/CMakeLists.txt
+++ lldb/source/Core/CMakeLists.txt
@@ -103,10 +103,6 @@
 # TODO: Remove once we have better layering
 set_target_properties(lldbCore PROPERTIES LINK_INTERFACE_MULTIPLICITY 5)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbCore PRIVATE ${LibEdit_INCLUDE_DIRS})
-e

[Lldb-commits] [PATCH] D124673: [llvm][lldb] use FindLibEdit.cmake everywhere

2022-04-29 Thread Tobias Ribizel via Phabricator via lldb-commits
upsj updated this revision to Diff 426080.
upsj added a comment.

improve handling of disabled libedit


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124673

Files:
  cmake/Modules/FindLibEdit.cmake
  lldb/cmake/modules/FindLibEdit.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/source/Core/CMakeLists.txt
  lldb/source/Host/CMakeLists.txt
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  llvm/cmake/config-ix.cmake
  llvm/lib/LineEditor/CMakeLists.txt
  llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn

Index: llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
@@ -142,7 +142,7 @@
   #   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
   # endif()
   # if (LLDB_ENABLE_LIBEDIT)
-  #   list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  #   list(APPEND EXTRA_LIBS LibEdit::LibEdit)
   # endif()
   # if (LLDB_ENABLE_LZMA)
   #   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
Index: llvm/lib/LineEditor/CMakeLists.txt
===
--- llvm/lib/LineEditor/CMakeLists.txt
+++ llvm/lib/LineEditor/CMakeLists.txt
@@ -1,5 +1,5 @@
 if(HAVE_LIBEDIT)
-  set(link_libs edit)
+  set(link_libs LibEdit::LibEdit)
 endif()
 
 add_llvm_component_library(LLVMLineEditor
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -64,7 +64,6 @@
 check_symbol_exists(FE_INEXACT "fenv.h" HAVE_DECL_FE_INEXACT)
 
 check_include_file(mach/mach.h HAVE_MACH_MACH_H)
-check_include_file(histedit.h HAVE_HISTEDIT_H)
 check_include_file(CrashReporterClient.h HAVE_CRASHREPORTERCLIENT_H)
 if(APPLE)
   include(CheckCSourceCompiles)
@@ -184,8 +183,9 @@
   # Don't look for these libraries on Windows.
   if (NOT PURE_WINDOWS)
 # Skip libedit if using ASan as it contains memory leaks.
-if (LLVM_ENABLE_LIBEDIT AND HAVE_HISTEDIT_H AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
-  check_library_exists(edit el_init "" HAVE_LIBEDIT)
+if (LLVM_ENABLE_LIBEDIT AND NOT LLVM_USE_SANITIZER MATCHES ".*Address.*")
+  find_package(LibEdit REQUIRED)
+  set(HAVE_LIBEDIT 1)
 else()
   set(HAVE_LIBEDIT 0)
 endif()
Index: lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
===
--- lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
+++ lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
@@ -10,7 +10,7 @@
 
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
 endif()
 
 add_lldb_library(lldbPluginScriptInterpreterPython PLUGIN
@@ -35,9 +35,3 @@
   LINK_COMPONENTS
 Support
   )
-
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbPluginScriptInterpreterPython PUBLIC
-${LibEdit_INCLUDE_DIRS}
-  )
-endif()
Index: lldb/source/Interpreter/CMakeLists.txt
===
--- lldb/source/Interpreter/CMakeLists.txt
+++ lldb/source/Interpreter/CMakeLists.txt
@@ -68,6 +68,3 @@
   LLDBInterpreterPropertiesGen
   LLDBInterpreterPropertiesEnumGen)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbInterpreter PRIVATE ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Host/CMakeLists.txt
===
--- lldb/source/Host/CMakeLists.txt
+++ lldb/source/Host/CMakeLists.txt
@@ -141,7 +141,7 @@
   list(APPEND EXTRA_LIBS ${CMAKE_DL_LIBS})
 endif()
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND EXTRA_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND EXTRA_LIBS LibEdit::LibEdit)
 endif()
 if (LLDB_ENABLE_LZMA)
   list(APPEND EXTRA_LIBS ${LIBLZMA_LIBRARIES})
@@ -151,7 +151,7 @@
 endif()
 
 if (LLDB_ENABLE_LIBEDIT)
-  list(APPEND LLDB_LIBEDIT_LIBS ${LibEdit_LIBRARIES})
+  list(APPEND LLDB_LIBEDIT_LIBS LibEdit::LibEdit)
   if (LLVM_BUILD_STATIC)
 list(APPEND LLDB_SYSTEM_LIBS gpm)
   endif()
@@ -171,6 +171,3 @@
 Support
   )
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbHost PUBLIC ${LibEdit_INCLUDE_DIRS})
-endif()
Index: lldb/source/Core/CMakeLists.txt
===
--- lldb/source/Core/CMakeLists.txt
+++ lldb/source/Core/CMakeLists.txt
@@ -103,10 +103,6 @@
 # TODO: Remove once we have better layering
 set_target_properties(lldbCore PROPERTIES LINK_INTERFACE_MULTIPLICITY 5)
 
-if (LLDB_ENABLE_LIBEDIT)
-  target_include_directories(lldbCore PRIVATE ${LibEdit_INCLUDE_DIRS})
-endif()
-
 if (LLDB_ENABLE_CURSES)
   target_include_directories(lldbCore PRIVATE ${CURSES_INCLUDE_DIRS})
 endif()
Index: lldb/cmake/modules/LLDBConfig.cmake

[Lldb-commits] [PATCH] D123502: [lldb][NFC] Refactor printing of short options in help

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Looks like it will do the job, and this version is definitely easier to read.

Were there any tests for the help output?  If not, maybe we should add one.

Other than that, LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123502

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


[Lldb-commits] [PATCH] D123204: [lldb] Fix initialization of LazyBool/bool variables m_overwrite/m_overwrite_lazy. NFCI.

2022-04-29 Thread Martin Storsjö via Phabricator via lldb-commits
mstorsjo added a comment.

Ping @jingham


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123204

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


[Lldb-commits] [PATCH] D124672: [lldb] Define LLDB_VERSION_PATCH correctly

2022-04-29 Thread Dimitry Andric via Phabricator via lldb-commits
dim updated this revision to Diff 426110.
dim added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Add llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn while we're here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124672

Files:
  lldb/include/lldb/Version/Version.inc.in
  llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn


Index: llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
@@ -9,7 +9,7 @@
 "LLDB_VERSION=$llvm_version",
 "LLDB_VERSION_MAJOR=$llvm_version_major",
 "LLDB_VERSION_MINOR=$llvm_version_minor",
-"LLDB_VERSION_PATCHLEVEL=$llvm_version_patch",
+"LLDB_VERSION_PATCH=$llvm_version_patch",
 "LLDB_FULL_VERSION_STRING=",
   ]
 }
Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"


Index: llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
@@ -9,7 +9,7 @@
 "LLDB_VERSION=$llvm_version",
 "LLDB_VERSION_MAJOR=$llvm_version_major",
 "LLDB_VERSION_MINOR=$llvm_version_minor",
-"LLDB_VERSION_PATCHLEVEL=$llvm_version_patch",
+"LLDB_VERSION_PATCH=$llvm_version_patch",
 "LLDB_FULL_VERSION_STRING=",
   ]
 }
Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D123500: [lldb][NFC] Add more tests for GenerateOptionsUsage

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Ah, tests for help that I asked for in another review...  Excellent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123500

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


[Lldb-commits] [lldb] 7abfaa0 - [lldb] Define LLDB_VERSION_PATCH correctly

2022-04-29 Thread Dimitry Andric via lldb-commits

Author: Dimitry Andric
Date: 2022-04-29T19:29:51+02:00
New Revision: 7abfaa0a815a37ef6abd3ad7eb169007bdc36619

URL: 
https://github.com/llvm/llvm-project/commit/7abfaa0a815a37ef6abd3ad7eb169007bdc36619
DIFF: 
https://github.com/llvm/llvm-project/commit/7abfaa0a815a37ef6abd3ad7eb169007bdc36619.diff

LOG: [lldb] Define LLDB_VERSION_PATCH correctly

In commit ccf1469a4cdb lldb got its own generated Version.inc file, with
`LLDB_VERSION` macros. However, it used `LLDB_VERSION_PATCHLEVEL`
instead of the actually correct `LLDB_VERSION_PATCH`. Correct this.

Reviewed By: JDevlieghere

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

Added: 


Modified: 
lldb/include/lldb/Version/Version.inc.in
llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn

Removed: 




diff  --git a/lldb/include/lldb/Version/Version.inc.in 
b/lldb/include/lldb/Version/Version.inc.in
index 5098bb1c2be5a..148bac2ffcff7 100644
--- a/lldb/include/lldb/Version/Version.inc.in
+++ b/lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"

diff  --git a/llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn 
b/llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
index 43987b3712623..2093c57c50763 100644
--- a/llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
+++ b/llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
@@ -9,7 +9,7 @@ write_cmake_config("version") {
 "LLDB_VERSION=$llvm_version",
 "LLDB_VERSION_MAJOR=$llvm_version_major",
 "LLDB_VERSION_MINOR=$llvm_version_minor",
-"LLDB_VERSION_PATCHLEVEL=$llvm_version_patch",
+"LLDB_VERSION_PATCH=$llvm_version_patch",
 "LLDB_FULL_VERSION_STRING=",
   ]
 }



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


[Lldb-commits] [PATCH] D124672: [lldb] Define LLDB_VERSION_PATCH correctly

2022-04-29 Thread Dimitry Andric via Phabricator via lldb-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7abfaa0a815a: [lldb] Define LLDB_VERSION_PATCH correctly 
(authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124672

Files:
  lldb/include/lldb/Version/Version.inc.in
  llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn


Index: llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
@@ -9,7 +9,7 @@
 "LLDB_VERSION=$llvm_version",
 "LLDB_VERSION_MAJOR=$llvm_version_major",
 "LLDB_VERSION_MINOR=$llvm_version_minor",
-"LLDB_VERSION_PATCHLEVEL=$llvm_version_patch",
+"LLDB_VERSION_PATCH=$llvm_version_patch",
 "LLDB_FULL_VERSION_STRING=",
   ]
 }
Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"


Index: llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/include/lldb/Version/BUILD.gn
@@ -9,7 +9,7 @@
 "LLDB_VERSION=$llvm_version",
 "LLDB_VERSION_MAJOR=$llvm_version_major",
 "LLDB_VERSION_MINOR=$llvm_version_minor",
-"LLDB_VERSION_PATCHLEVEL=$llvm_version_patch",
+"LLDB_VERSION_PATCH=$llvm_version_patch",
 "LLDB_FULL_VERSION_STRING=",
   ]
 }
Index: lldb/include/lldb/Version/Version.inc.in
===
--- lldb/include/lldb/Version/Version.inc.in
+++ lldb/include/lldb/Version/Version.inc.in
@@ -2,5 +2,5 @@
 #define LLDB_VERSION_STRING "@LLDB_VERSION@"
 #define LLDB_VERSION_MAJOR @LLDB_VERSION_MAJOR@
 #define LLDB_VERSION_MINOR @LLDB_VERSION_MINOR@
-#define LLDB_VERSION_PATCHLEVEL @LLDB_VERSION_PATCHLEVEL@
+#define LLDB_VERSION_PATCH @LLDB_VERSION_PATCH@
 #cmakedefine LLDB_FULL_VERSION_STRING "@LLDB_FULL_VERSION_STRING@"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D123204: [lldb] Fix initialization of LazyBool/bool variables m_overwrite/m_overwrite_lazy. NFCI.

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Thanks for these cleanups.  In actual fact, the values set for options in the 
constructor for CommandOptions are never used, only the values in 
OptionParsingStarted matter.  But it's still confusing to have them be wrong...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123204

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


[Lldb-commits] [PATCH] D117383: [lldb] Expose std::pair children for unordered_map

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.
Herald added a project: All.

Sorry for the delay here.

This output is definitely nicer than the previous version, so this change is 
desirable.

If you really are switching on unordered_map vrs. unordered_set behavior,  can 
you check the backend ValueObject's type to determine whether you are dealing 
with a map or set?  It might be nice to make that a little more explicit.  I 
can't see anything in this file that indicates that this synthetic child 
provider is used for both classes, so having something conditional on it being 
a map is surprising.




Comment at: lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp:128
+  // __cc is a field of __hash_value_type, which is a typedef.
+  if (name == "__cc")
+m_element_type = key_value_type.GetTypedefedType();

kastiglione wrote:
> This block of changes is needed to support `unordered_set`, because this 
> synthetic provider is shared by `unordered_set` and `unordered_map`.
> 
> For `unordered_map`, the element type is an internal hash node. For 
> `unoredered_set`, it's the type `T` from `unordered_set`. This part of the 
> code needs to know whether there's a hash node here, and to step down through 
> the `__cc` field.
> 
> I am not sure what the best way to do this is. I could do a string prefix 
> check against `std::__hash_value_type`. I could do a smarter full string 
> equality check, but could that possibly have false negatives if the wrong 
> string type name is constructed. As it currently is, I assume if there's a 
> one or more fields, and if the first one is named `__cc`, then it's assumed 
> to be an internal hash node.
> 
> Suggestions welcome.
IIUC, this depends on whether the backend is of type unordered_map or 
unordered_set?  Can you just check the type of the backend?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117383

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


[Lldb-commits] [PATCH] D124597: Select the correct DWARF location list entry when looking for variable locations

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

The change seems correct.  Since the test only requires -01, and the test code 
is quite straightforward, the test seems fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124597

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


[Lldb-commits] [lldb] dca2bc4 - Add a mutex to the ThreadPlanStackMap class.

2022-04-29 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-04-29T11:07:22-07:00
New Revision: dca2bc408186667346ab3bbb951adab44feba5bd

URL: 
https://github.com/llvm/llvm-project/commit/dca2bc408186667346ab3bbb951adab44feba5bd
DIFF: 
https://github.com/llvm/llvm-project/commit/dca2bc408186667346ab3bbb951adab44feba5bd.diff

LOG: Add a mutex to the ThreadPlanStackMap class.
We've seen very occasional crashes that we can only explain by
simultaneous access to the ThreadPlanStackMap, so I'm adding a
mutex to protect it.

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

Added: 


Modified: 
lldb/include/lldb/Target/ThreadPlanStack.h
lldb/source/Target/ThreadPlanStack.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/ThreadPlanStack.h 
b/lldb/include/lldb/Target/ThreadPlanStack.h
index 90f1ea3a284b9..e6a560a509261 100644
--- a/lldb/include/lldb/Target/ThreadPlanStack.h
+++ b/lldb/include/lldb/Target/ThreadPlanStack.h
@@ -123,11 +123,13 @@ class ThreadPlanStackMap {
   bool check_for_new = true);
 
   void AddThread(Thread &thread) {
+std::lock_guard guard(m_stack_map_mutex);
 lldb::tid_t tid = thread.GetID();
 m_plans_list.emplace(tid, thread);
   }
 
   bool RemoveTID(lldb::tid_t tid) {
+std::lock_guard guard(m_stack_map_mutex);
 auto result = m_plans_list.find(tid);
 if (result == m_plans_list.end())
   return false;
@@ -137,6 +139,7 @@ class ThreadPlanStackMap {
   }
 
   ThreadPlanStack *Find(lldb::tid_t tid) {
+std::lock_guard guard(m_stack_map_mutex);
 auto result = m_plans_list.find(tid);
 if (result == m_plans_list.end())
   return nullptr;
@@ -154,6 +157,7 @@ class ThreadPlanStackMap {
   }
 
   void Clear() {
+std::lock_guard guard(m_stack_map_mutex);
 for (auto &plan : m_plans_list)
   plan.second.ThreadDestroyed(nullptr);
 m_plans_list.clear();
@@ -172,8 +176,10 @@ class ThreadPlanStackMap {
 
 private:
   Process &m_process;
+  mutable std::recursive_mutex m_stack_map_mutex;
   using PlansList = std::unordered_map;
   PlansList m_plans_list;
+  
 };
 
 } // namespace lldb_private

diff  --git a/lldb/source/Target/ThreadPlanStack.cpp 
b/lldb/source/Target/ThreadPlanStack.cpp
index 80634647f9e05..ac7b44cef37d4 100644
--- a/lldb/source/Target/ThreadPlanStack.cpp
+++ b/lldb/source/Target/ThreadPlanStack.cpp
@@ -400,6 +400,7 @@ void ThreadPlanStackMap::Update(ThreadList ¤t_threads,
 bool delete_missing,
 bool check_for_new) {
 
+  std::lock_guard guard(m_stack_map_mutex);
   // Now find all the new threads and add them to the map:
   if (check_for_new) {
 for (auto thread : current_threads.Threads()) {
@@ -434,6 +435,7 @@ void ThreadPlanStackMap::DumpPlans(Stream &strm,
lldb::DescriptionLevel desc_level,
bool internal, bool condense_if_trivial,
bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   for (auto &elem : m_plans_list) {
 lldb::tid_t tid = elem.first;
 uint32_t index_id = 0;
@@ -470,6 +472,7 @@ bool ThreadPlanStackMap::DumpPlansForTID(Stream &strm, 
lldb::tid_t tid,
  bool internal,
  bool condense_if_trivial,
  bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   uint32_t index_id = 0;
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
 
@@ -509,6 +512,7 @@ bool ThreadPlanStackMap::DumpPlansForTID(Stream &strm, 
lldb::tid_t tid,
 
 bool ThreadPlanStackMap::PrunePlansForTID(lldb::tid_t tid) {
   // We only remove the plans for unreported TID's.
+  std::lock_guard guard(m_stack_map_mutex);
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
   if (thread_sp)
 return false;



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


[Lldb-commits] [PATCH] D124029: Add a mutex to the ThreadPlanStackMap to prevent it getting corrupted

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdca2bc408186: Add a mutex to the ThreadPlanStackMap class. 
(authored by jingham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124029

Files:
  lldb/include/lldb/Target/ThreadPlanStack.h
  lldb/source/Target/ThreadPlanStack.cpp


Index: lldb/source/Target/ThreadPlanStack.cpp
===
--- lldb/source/Target/ThreadPlanStack.cpp
+++ lldb/source/Target/ThreadPlanStack.cpp
@@ -400,6 +400,7 @@
 bool delete_missing,
 bool check_for_new) {
 
+  std::lock_guard guard(m_stack_map_mutex);
   // Now find all the new threads and add them to the map:
   if (check_for_new) {
 for (auto thread : current_threads.Threads()) {
@@ -434,6 +435,7 @@
lldb::DescriptionLevel desc_level,
bool internal, bool condense_if_trivial,
bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   for (auto &elem : m_plans_list) {
 lldb::tid_t tid = elem.first;
 uint32_t index_id = 0;
@@ -470,6 +472,7 @@
  bool internal,
  bool condense_if_trivial,
  bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   uint32_t index_id = 0;
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
 
@@ -509,6 +512,7 @@
 
 bool ThreadPlanStackMap::PrunePlansForTID(lldb::tid_t tid) {
   // We only remove the plans for unreported TID's.
+  std::lock_guard guard(m_stack_map_mutex);
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
   if (thread_sp)
 return false;
Index: lldb/include/lldb/Target/ThreadPlanStack.h
===
--- lldb/include/lldb/Target/ThreadPlanStack.h
+++ lldb/include/lldb/Target/ThreadPlanStack.h
@@ -123,11 +123,13 @@
   bool check_for_new = true);
 
   void AddThread(Thread &thread) {
+std::lock_guard guard(m_stack_map_mutex);
 lldb::tid_t tid = thread.GetID();
 m_plans_list.emplace(tid, thread);
   }
 
   bool RemoveTID(lldb::tid_t tid) {
+std::lock_guard guard(m_stack_map_mutex);
 auto result = m_plans_list.find(tid);
 if (result == m_plans_list.end())
   return false;
@@ -137,6 +139,7 @@
   }
 
   ThreadPlanStack *Find(lldb::tid_t tid) {
+std::lock_guard guard(m_stack_map_mutex);
 auto result = m_plans_list.find(tid);
 if (result == m_plans_list.end())
   return nullptr;
@@ -154,6 +157,7 @@
   }
 
   void Clear() {
+std::lock_guard guard(m_stack_map_mutex);
 for (auto &plan : m_plans_list)
   plan.second.ThreadDestroyed(nullptr);
 m_plans_list.clear();
@@ -172,8 +176,10 @@
 
 private:
   Process &m_process;
+  mutable std::recursive_mutex m_stack_map_mutex;
   using PlansList = std::unordered_map;
   PlansList m_plans_list;
+  
 };
 
 } // namespace lldb_private


Index: lldb/source/Target/ThreadPlanStack.cpp
===
--- lldb/source/Target/ThreadPlanStack.cpp
+++ lldb/source/Target/ThreadPlanStack.cpp
@@ -400,6 +400,7 @@
 bool delete_missing,
 bool check_for_new) {
 
+  std::lock_guard guard(m_stack_map_mutex);
   // Now find all the new threads and add them to the map:
   if (check_for_new) {
 for (auto thread : current_threads.Threads()) {
@@ -434,6 +435,7 @@
lldb::DescriptionLevel desc_level,
bool internal, bool condense_if_trivial,
bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   for (auto &elem : m_plans_list) {
 lldb::tid_t tid = elem.first;
 uint32_t index_id = 0;
@@ -470,6 +472,7 @@
  bool internal,
  bool condense_if_trivial,
  bool skip_unreported) {
+  std::lock_guard guard(m_stack_map_mutex);
   uint32_t index_id = 0;
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
 
@@ -509,6 +512,7 @@
 
 bool ThreadPlanStackMap::PrunePlansForTID(lldb::tid_t tid) {
   // We only remove the plans for unreported TID's.
+  std::lock_guard guard(m_stack_map_mutex);
   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(tid);
   if (thread_sp)
 return false;
Index: lldb/include/lldb/Target/ThreadPlanStack.h
===
--- lldb/include/lldb/Target/ThreadPlanStack.h
+++ lldb/include/lldb/Target/ThreadPlanStack.h
@@ -123,11 +123,13 @@
   b

[Lldb-commits] [lldb] aa7470a - Add a paragraph showing how to use container commands.

2022-04-29 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-04-29T11:11:52-07:00
New Revision: aa7470a1b31346f3509ba4b831be39fa1d327772

URL: 
https://github.com/llvm/llvm-project/commit/aa7470a1b31346f3509ba4b831be39fa1d327772
DIFF: 
https://github.com/llvm/llvm-project/commit/aa7470a1b31346f3509ba4b831be39fa1d327772.diff

LOG: Add a paragraph showing how to use container commands.

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

Added: 


Modified: 
lldb/docs/use/python-reference.rst

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e1e2f61eb5fec..a034cd29204f4 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -644,6 +644,51 @@ Now we can load the module into LLDB and use it
   -rw-r--r--@  1 someuser  wheel 6148 Jan 19 17:27 .DS_Store
   -rw---   1 someuser  wheel 7331 Jan 19 15:37 crash.log
 
+You can also make "container" commands to organize the commands you are adding 
to
+lldb.  Most of the lldb built-in commands structure themselves this way, and 
using
+a tree structure has the benefit of leaving the one-word command space free 
for user
+aliases.  It can also make it easier to find commands if you are adding more 
than
+a few of them.  Here's a trivial example of adding two "utility" commands into 
a
+"my-utilities" container:
+
+::
+
+  #!/usr/bin/env python
+
+  import lldb
+
+  def first_utility(debugger, command, result, internal_dict):
+  print("I am the first utility")
+
+  def second_utility(debugger, command, result, internal_dict):
+  print("I am the second utility")
+
+  # And the initialization code to add your commands
+  def __lldb_init_module(debugger, internal_dict):
+  debugger.HandleCommand('command container add -h "A container for my 
utilities" my-utilities')
+  debugger.HandleCommand('command script add -f my_utilities.first_utility 
-h "My first utility" my-utilities first')
+  debugger.HandleCommand('command script add -f 
my_utilities.second_utility -h "My second utility" my-utilities second')
+  print('The "my-utilities" python command has been installed and its 
subcommands are ready for use.')
+
+Then your new commands are available under the my-utilities node:
+
+::
+
+  (lldb) help my-utilities
+  A container for my utilities
+
+  Syntax: my-utilities
+
+  The following subcommands are supported:
+
+  first  -- My first utility  Expects 'raw' input (see 'help raw-input'.)
+  second -- My second utility  Expects 'raw' input (see 'help raw-input'.)
+
+  For more help on any particular subcommand, type 'help  
'.
+  (lldb) my-utilities first
+  I am the first utility
+
+
 A more interesting template has been created in the source repository that can
 help you to create lldb command quickly:
 



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


[Lldb-commits] [PATCH] D124028: Add some docs on how to use container commands to the python reference doc

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGaa7470a1b313: Add a paragraph showing how to use container 
commands. (authored by jingham).

Changed prior to commit:
  https://reviews.llvm.org/D124028?vs=423691&id=426128#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124028

Files:
  lldb/docs/use/python-reference.rst


Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -644,6 +644,51 @@
   -rw-r--r--@  1 someuser  wheel 6148 Jan 19 17:27 .DS_Store
   -rw---   1 someuser  wheel 7331 Jan 19 15:37 crash.log
 
+You can also make "container" commands to organize the commands you are adding 
to
+lldb.  Most of the lldb built-in commands structure themselves this way, and 
using
+a tree structure has the benefit of leaving the one-word command space free 
for user
+aliases.  It can also make it easier to find commands if you are adding more 
than
+a few of them.  Here's a trivial example of adding two "utility" commands into 
a
+"my-utilities" container:
+
+::
+
+  #!/usr/bin/env python
+
+  import lldb
+
+  def first_utility(debugger, command, result, internal_dict):
+  print("I am the first utility")
+
+  def second_utility(debugger, command, result, internal_dict):
+  print("I am the second utility")
+
+  # And the initialization code to add your commands
+  def __lldb_init_module(debugger, internal_dict):
+  debugger.HandleCommand('command container add -h "A container for my 
utilities" my-utilities')
+  debugger.HandleCommand('command script add -f my_utilities.first_utility 
-h "My first utility" my-utilities first')
+  debugger.HandleCommand('command script add -f 
my_utilities.second_utility -h "My second utility" my-utilities second')
+  print('The "my-utilities" python command has been installed and its 
subcommands are ready for use.')
+
+Then your new commands are available under the my-utilities node:
+
+::
+
+  (lldb) help my-utilities
+  A container for my utilities
+
+  Syntax: my-utilities
+
+  The following subcommands are supported:
+
+  first  -- My first utility  Expects 'raw' input (see 'help raw-input'.)
+  second -- My second utility  Expects 'raw' input (see 'help raw-input'.)
+
+  For more help on any particular subcommand, type 'help  
'.
+  (lldb) my-utilities first
+  I am the first utility
+
+
 A more interesting template has been created in the source repository that can
 help you to create lldb command quickly:
 


Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -644,6 +644,51 @@
   -rw-r--r--@  1 someuser  wheel 6148 Jan 19 17:27 .DS_Store
   -rw---   1 someuser  wheel 7331 Jan 19 15:37 crash.log
 
+You can also make "container" commands to organize the commands you are adding to
+lldb.  Most of the lldb built-in commands structure themselves this way, and using
+a tree structure has the benefit of leaving the one-word command space free for user
+aliases.  It can also make it easier to find commands if you are adding more than
+a few of them.  Here's a trivial example of adding two "utility" commands into a
+"my-utilities" container:
+
+::
+
+  #!/usr/bin/env python
+
+  import lldb
+
+  def first_utility(debugger, command, result, internal_dict):
+  print("I am the first utility")
+
+  def second_utility(debugger, command, result, internal_dict):
+  print("I am the second utility")
+
+  # And the initialization code to add your commands
+  def __lldb_init_module(debugger, internal_dict):
+  debugger.HandleCommand('command container add -h "A container for my utilities" my-utilities')
+  debugger.HandleCommand('command script add -f my_utilities.first_utility -h "My first utility" my-utilities first')
+  debugger.HandleCommand('command script add -f my_utilities.second_utility -h "My second utility" my-utilities second')
+  print('The "my-utilities" python command has been installed and its subcommands are ready for use.')
+
+Then your new commands are available under the my-utilities node:
+
+::
+
+  (lldb) help my-utilities
+  A container for my utilities
+
+  Syntax: my-utilities
+
+  The following subcommands are supported:
+
+  first  -- My first utility  Expects 'raw' input (see 'help raw-input'.)
+  second -- My second utility  Expects 'raw' input (see 'help raw-input'.)
+
+  For more help on any particular subcommand, type 'help  '.
+  (lldb) my-utilities first
+  I am the first utility
+
+
 A more interesting template has been created in the source repository that can
 help you to create lldb command quickly:
 
_

[Lldb-commits] [PATCH] D119997: Add a little test for simple breaking on overloaded functions by name

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.
Herald added a project: All.

This was submitted (dd8490d207d3a1612091abbea04bf660f133a89f 
) but I 
neglected to put the "Differential Revision" tag in the commit message so 
automation didn't pick that up...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119997

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


[Lldb-commits] [lldb] 268089b - Fix the encoding and decoding of UniqueCStringMap objects when saved to cache files.

2022-04-29 Thread Greg Clayton via lldb-commits

Author: Greg Clayton
Date: 2022-04-29T11:31:47-07:00
New Revision: 268089b6ac4bca2c87b272a61d7dcc6ad3e752e4

URL: 
https://github.com/llvm/llvm-project/commit/268089b6ac4bca2c87b272a61d7dcc6ad3e752e4
DIFF: 
https://github.com/llvm/llvm-project/commit/268089b6ac4bca2c87b272a61d7dcc6ad3e752e4.diff

LOG: Fix the encoding and decoding of UniqueCStringMap objects when saved to 
cache files.

UniqueCStringMap objects are a std::vector objects 
where the Entry object contains a ConstString + T. The values in the vector are 
sorted first by ConstString and then by the T value. ConstString objects are 
simply uniqued "const char *" values and when we compare we use the actual 
string pointer as the value we sort by. This caused a problem when we saved the 
symbol table name indexes and debug info indexes to disk in one process when 
they were sorted, and then loaded them into another process when decoding them 
from the cache files. Why? Because the order in which the ConstString objects 
were created are now completely different and the string pointers will no 
longer be sorted in the new process the cache was loaded into.

The unit tests created for the initial patch didn't catch the encoding and 
decoding issues of UniqueCStringMap because they were happening in the same 
process and encoding and decoding would end up createing sorted 
UniqueCStringMap objects due to the constant string pool being exactly the 
same.

This patch does the sort and also reserves the right amount of entries in the 
UniqueCStringMap::m_map prior to adding them all to avoid doing multiple 
allocations.

Added a unit test that loads an object file from yaml, and then I created a 
cache file for the original file and removed the cache file's signature mod 
time check since we will generate an object file from the YAML, and use that as 
the object file for the Symtab object. Then we load the cache data from the 
array of symtab cache bytes so that the ConstString "const char *" values will 
not match the current process, and verify we can lookup the 4 names from the 
object file in the symbol table.

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

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
lldb/source/Symbol/Symtab.cpp
lldb/unittests/Symbol/SymtabTest.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
index 413920f33619e..4db946c41221e 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
@@ -100,6 +100,7 @@ bool NameToDIE::Decode(const DataExtractor &data, 
lldb::offset_t *offset_ptr,
   if (identifier != kIdentifierNameToDIE)
 return false;
   const uint32_t count = data.GetU32(offset_ptr);
+  m_map.Reserve(count);
   for (uint32_t i = 0; i < count; ++i) {
 llvm::StringRef str(strtab.Get(data.GetU32(offset_ptr)));
 // No empty strings allowed in the name to DIE maps.
@@ -110,6 +111,16 @@ bool NameToDIE::Decode(const DataExtractor &data, 
lldb::offset_t *offset_ptr,
 else
   return false;
   }
+  // We must sort the UniqueCStringMap after decoding it since it is a vector
+  // of UniqueCStringMap::Entry objects which contain a ConstString and type T.
+  // ConstString objects are sorted by "const char *" and then type T and
+  // the "const char *" are point values that will depend on the order in which
+  // ConstString objects are created and in which of the 256 string pools they
+  // are created in. So after we decode all of the entries, we must sort the
+  // name map to ensure name lookups succeed. If we encode and decode within
+  // the same process we wouldn't need to sort, so unit testing didn't catch
+  // this issue when first checked in.
+  m_map.Sort(std::less());
   return true;
 }
 

diff  --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index d148706003adf..eb2447efbad1d 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -1204,6 +1204,7 @@ bool DecodeCStrMap(const DataExtractor &data, 
lldb::offset_t *offset_ptr,
   if (identifier != kIdentifierCStrMap)
 return false;
   const uint32_t count = data.GetU32(offset_ptr);
+  cstr_map.Reserve(count);
   for (uint32_t i=0; iPreloadSymbols();
   EncodeDecode(*module_symtab);
 }
+
+TEST_F(SymtabTest, TestDecodeCStringMaps) {
+  // Symbol tables save out the symbols, but they also save out the symbol 
table
+  // name indexes. These name indexes are a map of sorted ConstString + T pairs
+  // and when they are decoded from a file, they are no longer sorted since
+  // ConstString objects can be sorted by "const char *" and the order in which
+  // these strings are created won't be the same in a new process. We need to
+  // ensure these name lookups happen correctly when we load the name indexes,
+  // so this test 

[Lldb-commits] [PATCH] D124572: Fix the encoding and decoding of UniqueCStringMap objects when saved to cache files.

2022-04-29 Thread Greg Clayton via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG268089b6ac4b: Fix the encoding and decoding of 
UniqueCStringMap objects when saved to… (authored by clayborg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124572

Files:
  lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
  lldb/source/Symbol/Symtab.cpp
  lldb/unittests/Symbol/SymtabTest.cpp

Index: lldb/unittests/Symbol/SymtabTest.cpp
===
--- lldb/unittests/Symbol/SymtabTest.cpp
+++ lldb/unittests/Symbol/SymtabTest.cpp
@@ -303,3 +303,417 @@
   module_symtab->PreloadSymbols();
   EncodeDecode(*module_symtab);
 }
+
+TEST_F(SymtabTest, TestDecodeCStringMaps) {
+  // Symbol tables save out the symbols, but they also save out the symbol table
+  // name indexes. These name indexes are a map of sorted ConstString + T pairs
+  // and when they are decoded from a file, they are no longer sorted since
+  // ConstString objects can be sorted by "const char *" and the order in which
+  // these strings are created won't be the same in a new process. We need to
+  // ensure these name lookups happen correctly when we load the name indexes,
+  // so this test loads a symbol table from a cache file from
+  // "lldb/unittests/Symbol/Inputs/indexnames-symtab-cache" and make sure we
+  // can correctly lookup each of the names in the symbol table.
+  auto ExpectedFile = TestFile::fromYaml(R"(
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x10C
+  cpusubtype:  0x0
+  filetype:0x2
+  ncmds:   16
+  sizeofcmds:  744
+  flags:   0x200085
+  reserved:0x0
+LoadCommands:
+  - cmd: LC_SEGMENT_64
+cmdsize: 72
+segname: __PAGEZERO
+vmaddr:  0
+vmsize:  4294967296
+fileoff: 0
+filesize:0
+maxprot: 0
+initprot:0
+nsects:  0
+flags:   0
+  - cmd: LC_SEGMENT_64
+cmdsize: 232
+segname: __TEXT
+vmaddr:  4294967296
+vmsize:  16384
+fileoff: 0
+filesize:16384
+maxprot: 5
+initprot:5
+nsects:  2
+flags:   0
+Sections:
+  - sectname:__text
+segname: __TEXT
+addr:0x13F64
+size:76
+offset:  0x3F64
+align:   2
+reloff:  0x0
+nreloc:  0
+flags:   0x8400
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+content: 80018052C0035FD6E0028052C0035FD640048052C0035FD6FF8300D1FD7B01A9FD43009108008052E80B00B9BFC31FB8F497F597F697E00B40B9FD7B41A9FF830091C0035FD6
+  - sectname:__unwind_info
+segname: __TEXT
+addr:0x13FB0
+size:80
+offset:  0x3FB0
+align:   2
+reloff:  0x0
+nreloc:  0
+flags:   0x0
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+content: 01001C001C001C000200643F34003400B13F340003000C0002001400020118040002
+  - cmd: LC_SEGMENT_64
+cmdsize: 72
+segname: __LINKEDIT
+vmaddr:  4294983680
+vmsize:  16384
+fileoff: 16384
+filesize:994
+maxprot: 1
+initprot:1
+nsects:  0
+flags:   0
+  - cmd: LC_DYLD_CHAINED_FIXUPS
+cmdsize: 16
+dataoff: 16384
+datasize:56
+  - cmd: LC_DYLD_EXPORTS_TRIE
+cmdsize: 16
+dataoff: 16440
+datasize:80
+  - cmd: LC_SYMTAB
+cmdsize: 24
+symoff:  16528
+nsyms:   25
+stroff:  16928
+strsize: 176
+  - cmd: LC_DYSYMTAB
+cmdsize: 80
+ilocalsym:   0
+nlocalsym:   20
+iextdefsym:  20
+nextdefsym:  5
+iundefsym:   25
+nundefsym:   0
+tocoff:  0
+ntoc:0
+modtaboff:   0
+nmodtab: 0
+extrefsymoff:0
+nextrefsyms: 0
+indirectsymoff:  0
+nindirectsyms:   0
+extreloff:   0
+nextrel: 0
+locreloff:   0
+nlocrel: 0
+  - cmd: LC_LOAD_DYLINKER
+cmdsize: 32
+name:12
+Content: '/usr/lib/dyld'
+ZeroPadBytes:7
+  - cmd: LC_UUID
+cmdsize: 24
+uuid:3E94866E-0D1A-39BD-975B-64E8F1F

[Lldb-commits] [lldb] 2a84a86 - [lldb] Fix initialization of LazyBool/bool variables m_overwrite/m_overwrite_lazy. NFCI.

2022-04-29 Thread Martin Storsjö via lldb-commits

Author: Martin Storsjö
Date: 2022-04-29T21:33:37+03:00
New Revision: 2a84a86184392a7e18a958f36db0b2b3da6ae2bd

URL: 
https://github.com/llvm/llvm-project/commit/2a84a86184392a7e18a958f36db0b2b3da6ae2bd
DIFF: 
https://github.com/llvm/llvm-project/commit/2a84a86184392a7e18a958f36db0b2b3da6ae2bd.diff

LOG: [lldb] Fix initialization of LazyBool/bool variables 
m_overwrite/m_overwrite_lazy. NFCI.

This silences a GCC warning after
1f7b58f2a50461493f083b2ed807b25e036286f6 / D122680:

lldb/source/Commands/CommandObjectCommands.cpp:1650:22: warning: enum constant 
in boolean context [-Wint-in-bool-context]
 1650 |   bool m_overwrite = eLazyBoolCalculate;
  |  ^~

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

Added: 


Modified: 
lldb/source/Commands/CommandObjectCommands.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index 1d4687b0650a9..4ea81082a9aed 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1480,7 +1480,7 @@ class CommandObjectCommandsScriptAdd : public 
CommandObjectParsed,
 std::string m_class_name;
 std::string m_funct_name;
 std::string m_short_help;
-LazyBool m_overwrite_lazy;
+LazyBool m_overwrite_lazy = eLazyBoolCalculate;
 ScriptedCommandSynchronicity m_synchronicity =
 eScriptedCommandSynchronicitySynchronous;
   };
@@ -1647,7 +1647,7 @@ class CommandObjectCommandsScriptAdd : public 
CommandObjectParsed,
   std::string m_cmd_name;
   CommandObjectMultiword *m_container = nullptr;
   std::string m_short_help;
-  bool m_overwrite = eLazyBoolCalculate;
+  bool m_overwrite = false;
   ScriptedCommandSynchronicity m_synchronicity =
   eScriptedCommandSynchronicitySynchronous;
 };



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


[Lldb-commits] [PATCH] D123204: [lldb] Fix initialization of LazyBool/bool variables m_overwrite/m_overwrite_lazy. NFCI.

2022-04-29 Thread Martin Storsjö via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2a84a8618439: [lldb] Fix initialization of LazyBool/bool 
variables… (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123204

Files:
  lldb/source/Commands/CommandObjectCommands.cpp


Index: lldb/source/Commands/CommandObjectCommands.cpp
===
--- lldb/source/Commands/CommandObjectCommands.cpp
+++ lldb/source/Commands/CommandObjectCommands.cpp
@@ -1480,7 +1480,7 @@
 std::string m_class_name;
 std::string m_funct_name;
 std::string m_short_help;
-LazyBool m_overwrite_lazy;
+LazyBool m_overwrite_lazy = eLazyBoolCalculate;
 ScriptedCommandSynchronicity m_synchronicity =
 eScriptedCommandSynchronicitySynchronous;
   };
@@ -1647,7 +1647,7 @@
   std::string m_cmd_name;
   CommandObjectMultiword *m_container = nullptr;
   std::string m_short_help;
-  bool m_overwrite = eLazyBoolCalculate;
+  bool m_overwrite = false;
   ScriptedCommandSynchronicity m_synchronicity =
   eScriptedCommandSynchronicitySynchronous;
 };


Index: lldb/source/Commands/CommandObjectCommands.cpp
===
--- lldb/source/Commands/CommandObjectCommands.cpp
+++ lldb/source/Commands/CommandObjectCommands.cpp
@@ -1480,7 +1480,7 @@
 std::string m_class_name;
 std::string m_funct_name;
 std::string m_short_help;
-LazyBool m_overwrite_lazy;
+LazyBool m_overwrite_lazy = eLazyBoolCalculate;
 ScriptedCommandSynchronicity m_synchronicity =
 eScriptedCommandSynchronicitySynchronous;
   };
@@ -1647,7 +1647,7 @@
   std::string m_cmd_name;
   CommandObjectMultiword *m_container = nullptr;
   std::string m_short_help;
-  bool m_overwrite = eLazyBoolCalculate;
+  bool m_overwrite = false;
   ScriptedCommandSynchronicity m_synchronicity =
   eScriptedCommandSynchronicitySynchronous;
 };
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D124597: Select the correct DWARF location list entry when looking for variable locations

2022-04-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision.
clayborg added a comment.

I wonder if this will help optimized code debugging at all!? Good catch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124597

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


[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In D122974#3482720 , @llunak wrote:

> In D122974#3482556 , @labath wrote:
>
>> Interesting. I don't know if I missed this somewhere, but could explain what 
>> kind of a map operation can lldb perform without computing the hash at least 
>> once?
>
> All of them :). Computing is not the only way of obtaining the hash of a 
> string. LLDB index cache (settings set symbols.enable-lldb-index-cache true) 
> stores a big bunch of strings and when loading them back into ConstString the 
> next time djbHash() is ~15% of total CPU LLDB startup time. That could be 
> saved if the cache cached the hash values too.

If the string pool caches the hash value, we could actually write out the hash 
in the cache file to speed up loading. I didn't want to re-hash every string 
when I saved the strings out to the cache file due to the cost, but it would be 
interesting to look into to see if it improves performance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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


[Lldb-commits] [PATCH] D124579: Make partial function name matching match on context boundaries

2022-04-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/include/lldb/Target/Language.h:225
+  // symbol was really B::A::my_function.  We want that to be
+  // a match.  But we wouldn't want this to match AnotherB::A::my_function.  
The
+  // user is specifying a truncated path, not a truncated set of characters.

The comment should be adding something extra to "A" right? See suggested code 
change 



Comment at: lldb/source/Core/Module.cpp:753-754
+llvm::StringRef full_name = sc.GetFunctionName().GetStringRef();
+if (full_name.empty() && sc.symbol)
+full_name = sc.symbol->GetName().GetStringRef();
+// We always keep unnamed symbols:

Remove this, SymbolContext::GetFunctionName() already returns the symbol name 
if there is no block with inlined function name or concrete function name.



Comment at: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:330-359
+//  size_t from = 0;
+//  llvm::StringRef demangled_ref = demangled.GetStringRef();
+//  size_t dem_len = demangled_ref.size();
+//  size_t path_len = path.size();
+//  
+//  // The path string might appear more than once in the demangled string.  A
+//  // silly example is:

shafik wrote:
> dead code?
delete commented out code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124579

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


[Lldb-commits] [lldb] 6e56c49 - Decr pc when looking for DWARF loc list entry mid-stack

2022-04-29 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2022-04-29T14:34:06-07:00
New Revision: 6e56c4961a106b8fde69ffcf9f803fe0890722fa

URL: 
https://github.com/llvm/llvm-project/commit/6e56c4961a106b8fde69ffcf9f803fe0890722fa
DIFF: 
https://github.com/llvm/llvm-project/commit/6e56c4961a106b8fde69ffcf9f803fe0890722fa.diff

LOG: Decr pc when looking for DWARF loc list entry mid-stack

When looking for a variable location in a DWARF location list,
we search the list of ranges to find one that includes the pc.
With a function mid-stack, the "pc" is the return pc instead of
the call instruction, and in optimized code this can be another
function or a different basic block (with different variable
locations).  Back up the "pc" value mid-stack to find the correct
location list entry.

Differential Revision: https://reviews.llvm.org/D124597
rdar://63903416

Added: 
lldb/test/API/functionalities/location-list-lookup/Makefile
lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
lldb/test/API/functionalities/location-list-lookup/main.c

Modified: 
lldb/source/Expression/DWARFExpression.cpp

Removed: 




diff  --git a/lldb/source/Expression/DWARFExpression.cpp 
b/lldb/source/Expression/DWARFExpression.cpp
index 717cbe76450eb..1f11907dc64c4 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -858,29 +858,28 @@ bool DWARFExpression::Evaluate(ExecutionContext *exe_ctx,
   ModuleSP module_sp = m_module_wp.lock();
 
   if (IsLocationList()) {
-addr_t pc;
+Address pc;
 StackFrame *frame = nullptr;
-if (reg_ctx)
-  pc = reg_ctx->GetPC();
-else {
+if (!reg_ctx || !reg_ctx->GetPCForSymbolication(pc)) {
   frame = exe_ctx->GetFramePtr();
   if (!frame)
 return false;
   RegisterContextSP reg_ctx_sp = frame->GetRegisterContext();
   if (!reg_ctx_sp)
 return false;
-  pc = reg_ctx_sp->GetPC();
+  reg_ctx_sp->GetPCForSymbolication(pc);
 }
 
 if (func_load_addr != LLDB_INVALID_ADDRESS) {
-  if (pc == LLDB_INVALID_ADDRESS) {
+  if (!pc.IsValid()) {
 if (error_ptr)
   error_ptr->SetErrorString("Invalid PC in frame.");
 return false;
   }
 
-  if (llvm::Optional expr =
-  GetLocationExpression(func_load_addr, pc)) {
+  Target *target = exe_ctx->GetTargetPtr();
+  if (llvm::Optional expr = GetLocationExpression(
+  func_load_addr, pc.GetLoadAddress(target))) {
 return DWARFExpression::Evaluate(
 exe_ctx, reg_ctx, module_sp, *expr, m_dwarf_cu, m_reg_kind,
 initial_value_ptr, object_address_ptr, result, error_ptr);
@@ -2862,7 +2861,7 @@ bool DWARFExpression::MatchesOperand(StackFrame &frame,
 if (load_function_start == LLDB_INVALID_ADDRESS)
   return false;
 
-addr_t pc = frame.GetFrameCodeAddress().GetLoadAddress(
+addr_t pc = frame.GetFrameCodeAddressForSymbolication().GetLoadAddress(
 frame.CalculateTarget().get());
 
 if (llvm::Optional expr =

diff  --git a/lldb/test/API/functionalities/location-list-lookup/Makefile 
b/lldb/test/API/functionalities/location-list-lookup/Makefile
new file mode 100644
index 0..78b0b11cb7484
--- /dev/null
+++ b/lldb/test/API/functionalities/location-list-lookup/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -O1
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
new file mode 100644
index 0..2121610899b3e
--- /dev/null
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -0,0 +1,40 @@
+"""Test that lldb picks the correct DWARF location list entry with a 
return-pc out of bounds."""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class LocationListLookupTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+def test_loclist(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+self.dbg.SetAsync(False)
+
+li = lldb.SBLaunchInfo(["a.out"])
+error = lldb.SBError()
+process = target.Launch(li, error)
+self.assertTrue(process.IsValid())
+self.assertTrue(process.is_stopped)
+
+# Find `main` on the stack, then 
+# find `argv` local variable, then
+# check that we can read the c-string in argv[0]
+for f in process.GetSelectedThread().frames:
+if f.GetDisplayFunctionName() == "main":
+  

[Lldb-commits] [PATCH] D124597: Select the correct DWARF location list entry when looking for variable locations

2022-04-29 Thread Jason Molenda via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6e56c4961a10: Decr pc when looking for DWARF loc list entry 
mid-stack (authored by jasonmolenda).

Changed prior to commit:
  https://reviews.llvm.org/D124597?vs=425703&id=426166#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124597

Files:
  lldb/source/Expression/DWARFExpression.cpp
  lldb/test/API/functionalities/location-list-lookup/Makefile
  lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
  lldb/test/API/functionalities/location-list-lookup/main.c

Index: lldb/test/API/functionalities/location-list-lookup/main.c
===
--- /dev/null
+++ lldb/test/API/functionalities/location-list-lookup/main.c
@@ -0,0 +1,23 @@
+#include 
+#include 
+
+// The goal with this test is:
+//  1. Have main() followed by foo()
+//  2. Have the no-return call to abort() in main be the last instruction
+//  3. Have the next instruction be the start of foo()
+//  4. The debug info for argv uses a location list.
+// clang at -O1 on x86_64 or arm64 has debuginfo like
+//  DW_AT_location	(0x0049:
+//  [0x00013f15, 0x00013f25): DW_OP_reg4 RSI
+//  [0x00013f25, 0x00013f5b): DW_OP_reg15 R15)
+
+void foo(int);
+int main(int argc, char **argv) {
+  char *file = argv[0];
+  char f0 = file[0];
+  printf("%c\n", f0);
+  foo(f0);
+  printf("%s %d\n", argv[0], argc);
+  abort(); /// argv is still be accessible here
+}
+void foo(int in) { printf("%d\n", in); }
Index: lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
===
--- /dev/null
+++ lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -0,0 +1,40 @@
+"""Test that lldb picks the correct DWARF location list entry with a return-pc out of bounds."""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class LocationListLookupTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+def test_loclist(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+self.dbg.SetAsync(False)
+
+li = lldb.SBLaunchInfo(["a.out"])
+error = lldb.SBError()
+process = target.Launch(li, error)
+self.assertTrue(process.IsValid())
+self.assertTrue(process.is_stopped)
+
+# Find `main` on the stack, then 
+# find `argv` local variable, then
+# check that we can read the c-string in argv[0]
+for f in process.GetSelectedThread().frames:
+if f.GetDisplayFunctionName() == "main":
+argv = f.GetValueForVariablePath("argv").GetChildAtIndex(0)
+strm = lldb.SBStream()
+argv.GetDescription(strm)
+self.assertNotEqual(strm.GetData().find('a.out'), -1)
Index: lldb/test/API/functionalities/location-list-lookup/Makefile
===
--- /dev/null
+++ lldb/test/API/functionalities/location-list-lookup/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -O1
+include Makefile.rules
Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -858,29 +858,28 @@
   ModuleSP module_sp = m_module_wp.lock();
 
   if (IsLocationList()) {
-addr_t pc;
+Address pc;
 StackFrame *frame = nullptr;
-if (reg_ctx)
-  pc = reg_ctx->GetPC();
-else {
+if (!reg_ctx || !reg_ctx->GetPCForSymbolication(pc)) {
   frame = exe_ctx->GetFramePtr();
   if (!frame)
 return false;
   RegisterContextSP reg_ctx_sp = frame->GetRegisterContext();
   if (!reg_ctx_sp)
 return false;
-  pc = reg_ctx_sp->GetPC();
+  reg_ctx_sp->GetPCForSymbolication(pc);
 }
 
 if (func_load_addr != LLDB_INVALID_ADDRESS) {
-  if (pc == LLDB_INVALID_ADDRESS) {
+  if (!pc.IsValid()) {
 if (error_ptr)
   error_ptr->SetErrorString("Invalid PC in frame.");
 return false;
   }
 
-  if (llvm::Optional expr =
-  GetLocationExpression(func_load_addr, pc)) {
+  Target *target = exe_ctx->GetTargetPtr();
+  if (llvm::Optional expr = GetLocationExpression(
+  func_load_addr, pc.GetLoadAddress(target))) {
 return DWARFExpression::Evaluate(
 exe_ctx, reg_ctx, module_sp, *

[Lldb-commits] [PATCH] D124597: Select the correct DWARF location list entry when looking for variable locations

2022-04-29 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added a comment.

In D124597#3483197 , @clayborg wrote:

> I wonder if this will help optimized code debugging at all!? Good catch

It came up in a kernel debugging session iirc; it was the case of a function 
doing a noreturn call, and when you went up to that stack frame, the variable 
was in one register up through the noreturn call, and then it was in a 
different register after that noreturn -- so we would print the wrong register 
value. :/  It takes a bit to get this exact issue, but printing an incorrect 
value was a worst case failure mode.  The API test case I came up with will 
only print that the variable is unavailable, instead of the wrong value.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124597

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


[Lldb-commits] [PATCH] D124579: Make partial function name matching match on context boundaries

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham updated this revision to Diff 426170.
jingham added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124579

Files:
  lldb/include/lldb/Target/Language.h
  lldb/source/Core/Module.cpp
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
  lldb/source/Target/Language.cpp
  lldb/test/API/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
  lldb/test/API/functionalities/breakpoint/cpp/main.cpp
  lldb/test/API/functionalities/return-value/TestReturnValue.py
  lldb/test/API/macosx/indirect_symbol/TestIndirectSymbols.py
  lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp

Index: lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
===
--- lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
+++ lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
@@ -123,6 +123,37 @@
   }
 }
 
+TEST(CPlusPlusLanguage, ContainsPath) {
+  CPlusPlusLanguage::MethodName 
+  reference_1(ConstString("int foo::bar::func01(int a, double b)"));
+  CPlusPlusLanguage::MethodName
+  reference_2(ConstString("int foofoo::bar::func01(std::string a, int b)"));
+  CPlusPlusLanguage::MethodName reference_3(ConstString("int func01()"));
+  CPlusPlusLanguage::MethodName 
+  reference_4(ConstString("bar::baz::operator bool()"));
+  
+  EXPECT_TRUE(reference_1.ContainsPath("func01"));
+  EXPECT_TRUE(reference_1.ContainsPath("bar::func01"));
+  EXPECT_TRUE(reference_1.ContainsPath("foo::bar::func01"));
+  EXPECT_FALSE(reference_1.ContainsPath("func"));
+  EXPECT_FALSE(reference_1.ContainsPath("baz::func01"));
+  EXPECT_FALSE(reference_1.ContainsPath("::bar::func01"));
+  EXPECT_FALSE(reference_1.ContainsPath("::foo::baz::func01"));
+  EXPECT_FALSE(reference_1.ContainsPath("foo::bar::baz::func01"));
+  
+  EXPECT_TRUE(reference_2.ContainsPath("foofoo::bar::func01"));
+  EXPECT_FALSE(reference_2.ContainsPath("foo::bar::func01"));
+  
+  EXPECT_TRUE(reference_3.ContainsPath("func01"));
+  EXPECT_FALSE(reference_3.ContainsPath("func"));
+  EXPECT_FALSE(reference_3.ContainsPath("bar::func01"));
+
+  EXPECT_TRUE(reference_4.ContainsPath("operator bool"));
+  EXPECT_TRUE(reference_4.ContainsPath("baz::operator bool"));
+  EXPECT_TRUE(reference_4.ContainsPath("bar::baz::operator bool"));
+  EXPECT_FALSE(reference_4.ContainsPath("az::operator bool"));
+}
+
 TEST(CPlusPlusLanguage, ExtractContextAndIdentifier) {
   struct TestCase {
 std::string input;
Index: lldb/test/API/macosx/indirect_symbol/TestIndirectSymbols.py
===
--- lldb/test/API/macosx/indirect_symbol/TestIndirectSymbols.py
+++ lldb/test/API/macosx/indirect_symbol/TestIndirectSymbols.py
@@ -98,7 +98,7 @@
 # make sure we are again in out target function.
 break_reexported = target.BreakpointCreateByName(
 "reexport_to_indirect")
-self.assertTrue(break_reexported, VALID_BREAKPOINT)
+self.assertEqual(break_reexported.GetNumLocations(), 1, VALID_BREAKPOINT)
 
 # Now continue should take us to the second call through the indirect
 # symbol:
Index: lldb/test/API/functionalities/return-value/TestReturnValue.py
===
--- lldb/test/API/functionalities/return-value/TestReturnValue.py
+++ lldb/test/API/functionalities/return-value/TestReturnValue.py
@@ -237,7 +237,7 @@
 
 # Set the breakpoint, run to it, finish out.
 bkpt = self.target.BreakpointCreateByName(func_name)
-self.assertTrue(bkpt.GetNumResolvedLocations() > 0)
+self.assertTrue(bkpt.GetNumResolvedLocations() > 0, "Got wrong number of locations for {0}".format(func_name))
 
 self.process.Continue()
 
Index: lldb/test/API/functionalities/breakpoint/cpp/main.cpp
===
--- lldb/test/API/functionalities/breakpoint/cpp/main.cpp
+++ lldb/test/API/functionalities/breakpoint/cpp/main.cpp
@@ -24,6 +24,29 @@
 c::~c() {}
 }
 
+namespace aa {
+class cc {
+public:
+cc();
+~cc();
+void func1() 
+{
+puts (__PRETTY_FUNCTION__);
+}
+void func2() 
+{
+puts (__PRETTY_FUNCTION__);
+}
+void func3() 
+{
+puts (__PRETTY_FUNCTION__);
+}
+};
+
+cc::cc() {}
+cc::~cc() {}
+}
+
 namespace b {
 class c {
 public:
@@ -62,11 +85,15 @@
 int main (int argc, char const *argv[])
 {
 a::c ac;
+aa::cc aac;
 b::c bc;
 c::d cd;
 ac.func1();
 ac.func2();
 ac.func3();
+aac.func1();
+aac.func2();
+aac.func3();
 bc.func1();
 bc.func3();
 cd.func2();
Index: lldb/test/API/functionalities/breakp

[Lldb-commits] [PATCH] D124579: Make partial function name matching match on context boundaries

2022-04-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham marked 6 inline comments as done.
jingham added inline comments.



Comment at: lldb/include/lldb/Target/Language.h:225
+  // symbol was really B::A::my_function.  We want that to be
+  // a match.  But we wouldn't want this to match AnotherB::A::my_function.  
The
+  // user is specifying a truncated path, not a truncated set of characters.

clayborg wrote:
> The comment should be adding something extra to "A" right? See suggested code 
> change 
Yes, the comment was wrong.  I had a fancier example that was taking too many 
characters and I didn't delete enough when simplifying.  But I'm not sure what 
code change you are referring to?  I don't see how this is related to 
GetFunctionName.



Comment at: lldb/source/Core/Module.cpp:753-754
+llvm::StringRef full_name = sc.GetFunctionName().GetStringRef();
+if (full_name.empty() && sc.symbol)
+full_name = sc.symbol->GetName().GetStringRef();
+// We always keep unnamed symbols:

clayborg wrote:
> Remove this, SymbolContext::GetFunctionName() already returns the symbol name 
> if there is no block with inlined function name or concrete function name.
Yeah, I swear I saw a case debugging through this where GetFunctionName was 
returning a null string but going to the Symbol worked, but reading through 
GetFunctionName I don't see how that could be and I can't reproduce the 
problem, so I must have been seeing some unrelated error.



Comment at: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:293-309
+  // Incoming path has context but this method does not, no match.
+  if (m_context.empty())
+return false;
+
+  // Make sure the incoming path's context is found in the method context:
+  size_t path_pos = m_context.rfind(context);
+  if (path_pos == llvm::StringRef::npos)

labath wrote:
> ```
> StringRef haystack = m_context;
> if (!haystack.consume_back(context))
>   return false;
> if (haystack.empty() || !isalnum(haystack.back()))
>   return true;
> return false;
> ```
Much nicer, thanks!



Comment at: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:330
+
+//  size_t from = 0;
+//  llvm::StringRef demangled_ref = demangled.GetStringRef();

clayborg wrote:
> shafik wrote:
> > dead code?
> delete commented out code
Yup, that was the not very good (but much easier to implement) first try.  It's 
gone...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124579

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


[Lldb-commits] [lldb] 9c8179f - LocationListLookup test case failing on lldb-arm-ubuntu

2022-04-29 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2022-04-29T15:00:20-07:00
New Revision: 9c8179f9ce10158d6a9f28ec932e2facfde413d8

URL: 
https://github.com/llvm/llvm-project/commit/9c8179f9ce10158d6a9f28ec932e2facfde413d8
DIFF: 
https://github.com/llvm/llvm-project/commit/9c8179f9ce10158d6a9f28ec932e2facfde413d8.diff

LOG: LocationListLookup test case failing on lldb-arm-ubuntu

Skip on linux+arm for now until I can try to repo the setup of the
lldb-arm-ubuntu bot.  The name of the binary in argv[0] was not
able to be retrieved here; if the compiler's codegen had it stored
in a caller saved register, because it's not needed at this point,
it may not be retreivable.

Added: 


Modified: 
lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
index 2121610899b3..122d1a4ae8c1 100644
--- 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -14,6 +14,7 @@ def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
 
+@skipIf(oslist=["linux"], archs=["arm"])
 def test_loclist(self):
 self.build()
 exe = self.getBuildArtifact("a.out")



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


[Lldb-commits] [PATCH] D124314: lldb: Disable unittests if llvm_gtest target does not exist

2022-04-29 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

Could this go in LLDBStandalone.cmake?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124314

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


[Lldb-commits] [PATCH] D122974: prevent ConstString from calling djbHash() more than once

2022-04-29 Thread Luboš Luňák via Phabricator via lldb-commits
llunak added a comment.

In D122974#3483203 , @clayborg wrote:

> If the string pool caches the hash value, we could actually write out the 
> hash in the cache file to speed up loading.

The patch doing that is D124704  (except for 
the string pool caching).

> I didn't want to re-hash every string when I saved the strings out to the 
> cache file due to the cost, but it would be interesting to look into to see 
> if it improves performance.

I can measure 10% startup time saved when everything is already cached. Funnily 
enough, profiler consistently claims that saving caches got faster too (I 
already use D122975 ).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122974

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