[Lldb-commits] [PATCH] D92643: [lldb] Lookup static const members in FindGlobalVariables

2021-02-06 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil added a comment.

@werat I see you are aware of D81471 . Do you 
or someone else have anything against it? I find it more integrated using the 
clang type for it but I admit I do not understand the clang integration much. 
At least it handles more cases, I stopped after finding:

  $ echo 'struct Vars { static const int i = 2; } v; int main() {}'|./bin/clang 
-Wall -g -x c++ -;./bin/lldb -b ./a.out -o 'p Vars::i'
  error: Can't evaluate the expression without a running target due to: 
Interpreter doesn't handle one of the expression's operands
  vs. D81471's:
  (const int) $0 = 2




Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3162
+case DW_AT_decl_file:
+  decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
+  form_value.Unsigned()));

Here should be according to my D91014:
```
decl.SetFile(attributes.CompileUnitAtIndex(i)->GetFile(
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92643

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

[Lldb-commits] [PATCH] D92223: [lldb] Add support for looking up static const members

2021-02-06 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil added a comment.

This patch may be superseded by D92643 , not 
sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92223

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

[Lldb-commits] [PATCH] D92223: [lldb] Add support for looking up static const members

2021-02-06 Thread Andy Yankovsky via Phabricator via lldb-commits 
werat added a comment.

In D92223#2546736 , @jankratochvil 
wrote:

> This patch may be superseded by D92643 , not 
> sure.

Yeah, D92643  is an alternative way to 
implement this, according to @labath comments. Sorry I didn't make it clear.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92223

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

[Lldb-commits] [PATCH] D92643: [lldb] Lookup static const members in FindGlobalVariables

2021-02-06 Thread Andy Yankovsky via Phabricator via lldb-commits 
werat added a comment.

Thanks for reviewing!

In D92643#2546732 , @jankratochvil 
wrote:

> @werat I see you are aware of D81471 . Do 
> you or someone else have anything against it? I find it more integrated using 
> the clang type for it but I admit I do not understand the clang integration 
> much.

I don't have anything against it, on the contrary I'm all for it :) As a matter 
of fact, we've already integrated that patch in our internal LLDB fork a while 
ago.

But my patch is not a replacement for that one, it complements it by enhancing 
the `SBTarget:: FindGlobalVariables` API.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92643

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

[Lldb-commits] [PATCH] D96194: Defer the decision whether to use the CU or TU index until after reading the unit header.

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Nice catch. Regarding the implementation, I think it might be slightly cleaner 
(and slightly more consistent with the llvm dwarf parser) if the index handling 
has moved to the DWARFUnit class (as there's nothing to be gained now by doing 
it higher up). In `DWARFUnit::extract`, you could do something like:

  if (dwarf.GetDWARFContext().isDWO()) {
cu_index = &dwarf.GetDWARFContext().GetAsLLVM().getCUIndex();
...




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp:808-809
 
+  if (cu_index && (header.m_unit_type == llvm::dwarf::DW_UT_compile ||
+   header.m_unit_type == llvm::dwarf::DW_UT_split_compile)) {
+header.m_index_entry = cu_index->getFromOffset(header.m_offset);

I guess this could be `header.IsTypeUnit()` (and `!header.IsTypeUnit())`)...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96194

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

[Lldb-commits] [PATCH] D96176: Implement jAttachWait

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

I'm not sure this new functionality is really worth the new packet (or two), 
but if it solves a use case you care about, then I suppose that's fine. One 
alternative could be to just tack on some extra data to the existing vAttach 
family packets  (`vAttachWait;foo;interval:47;duration=74`).

> Lastly, this current implementation has a bug I couldn't figure out, where if 
> we're sending l an error response, lldb loses connection to lldb-server (this 
> happens even if the first thing I do in the handle_jAttachWait function is 
> return an error)

I'm not sure that's a bug (i.e., lldb may be intentionally dropping the 
connection). What would you expect lldb to do when it gets an error response?

> and, also, CTRL+C from lldb doesn't interrupt lldb-server. If anyone know why 
> this might be happening, I'd be glad to hear it.

Seems to work for me (in that I get back to the lldb prompt and the server 
connection is terminated), if I press ^C **twice**.

  $ bin/lldb
  (lldb) process attach --name asdgoijhpweiogjawe -w
  ^C^C
  ... Interrupted.
  (lldb) ^D




Comment at: lldb/include/lldb/Target/Process.h:113-114
 m_plugin_name(), m_resume_count(0), m_wait_for_launch(false),
+m_wait_for_launch_interval(llvm::Optional()),
+m_wait_for_launch_duration(llvm::Optional()),
 m_ignore_existing(true), m_continue_once_attached(false),

Just delete this, that's the default. If you really want to be explicit, you 
can put ` = llvm::None` in the member declaration.



Comment at: lldb/include/lldb/Target/Process.h:223-224
   bool m_wait_for_launch;
+  llvm::Optional m_wait_for_launch_interval;
+  llvm::Optional m_wait_for_launch_duration;
   bool m_ignore_existing;

clayborg wrote:
> Should we attach _usec and sec to these names to make it clear what the units 
> are?
I'd make that std::chrono::(micro)seconds



Comment at: lldb/include/lldb/Utility/StringExtractorGDBRemote.h:136
 eServerPacketType_vAttachOrWait,
+eServerPacketType_jAttachWait,
 eServerPacketType_vAttachName,

clayborg wrote:
> So we currently have 4 flavors from the old way: vAttach, vAttachWait 
> vAttachOrWait, vAttachName. Do we want to possibly make a "jAttach" that 
> works for all cases? The new "jAttach" could be powerful enough to do it all 
> in one packet if needed. I just worry about attaching the "Wait" to the 
> "jAttachWait" command name in case we want to use it for all of the above 
> cases at a later point. 
> 
> A "jAttach" could implement all of:
> - attach to existing pid
> - attach to by name
>   - unique existing process
>   - wait
> - allow existing (true/false)
> - poll interval (time in usec)
> - wait duration (time in sec)
> 
> Not that we need to add support for all of these flavor with this patch, I'm 
> just trying to forward think about the future in case other attach flags are 
> added to any flavor of attach. 
Sounds like a good idea.



Comment at: lldb/include/lldb/lldb-enumerations.h:600-601
   eArgTypeModuleUUID,
+  eArgTypeWaitforInterval,
+  eArgTypeWaitforDuration,
   eArgTypeLastArg // Always keep this entry as the last entry in this

What's up with this? Though this is the first time I see this table, I suspect 
it is not necessary to create a new command argument



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:261-273
+bool GDBRemoteCommunicationClient::GetJAttachWaitSupported() {
+  if (m_j_attach_wait_reply == eLazyBoolCalculate) {
+m_j_attach_wait_reply = eLazyBoolNo;
+
+StringExtractorGDBRemote response;
+if (SendPacketAndWaitForResponse("qJAttachWaitSupported", response,
+ false) == PacketResult::Success) {

I'm not sure this is really useful. We could infer that the packet is not 
supported by the "unsupported" response to the packet itself...



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:388
 
+  auto now = std::chrono::system_clock::now();
+  auto target = now;

I think this ought to be `steady_clock`



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:394
   ProcessInstanceInfoList loop_process_list;
-  while (true) {
+  while (!timeout.hasValue() || now < target) {
 loop_process_list.clear();

`<= target` ? In case of a zero timeout, I guess this should loop at least 
once. Or, even better:
```
do {
  ...
} while (std::chrono::steady_clock::now() < target);
```
(At that point it does not matter whether it's `<` or `<=`).



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3379-3380
+  StringRef process_name;
+  auto polling_interval = llvm::Optional();
+  auto pollin

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

It doesn't look //too// bad, but what's up with the `friend` thingy? What's 
that used for? Can we get rid of it?


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

https://reviews.llvm.org/D95802

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

[Lldb-commits] [PATCH] D96201: [nfc] [lldb] Add Dwo assert

2021-02-06 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil created this revision.
jankratochvil added a reviewer: labath.
jankratochvil added a project: LLDB.
Herald added a subscriber: JDevlieghere.
jankratochvil requested review of this revision.

I had it in my local patchset and I did not want to drop it, OK for check-in?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96201

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp


Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -532,6 +532,9 @@
   if (die_offset == DW_INVALID_OFFSET)
 return DWARFDIE(); // Not found
 
+  // SymbolFileDWARF::GetDIE should have found the dwo file already.
+  lldbassert(!GetDwoSymbolFile());
+
   if (!ContainsDIEOffset(die_offset)) {
 GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
 "GetDIE for DIE 0x%" PRIx32 " is outside of its CU 0x%" PRIx32,


Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -532,6 +532,9 @@
   if (die_offset == DW_INVALID_OFFSET)
 return DWARFDIE(); // Not found
 
+  // SymbolFileDWARF::GetDIE should have found the dwo file already.
+  lldbassert(!GetDwoSymbolFile());
+
   if (!ContainsDIEOffset(die_offset)) {
 GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
 "GetDIE for DIE 0x%" PRIx32 " is outside of its CU 0x%" PRIx32,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D96202: [lldb/test] Automatically find debug servers to test

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath created this revision.
labath added reviewers: JDevlieghere, rupprecht.
Herald added a subscriber: mgorny.
labath requested review of this revision.
Herald added a project: LLDB.

Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.

A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.

One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.

A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").

Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96202

Files:
  lldb/packages/Python/lldbsuite/test/dotest.py
  lldb/packages/Python/lldbsuite/test/dotest_args.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  lldb/test/API/CMakeLists.txt
  lldb/test/API/commands/platform/sdk/TestPlatformSDK.py
  lldb/test/API/lit.site.cfg.py.in
  lldb/utils/lldb-dotest/CMakeLists.txt
  lldb/utils/lldb-dotest/lldb-dotest.in

Index: lldb/utils/lldb-dotest/lldb-dotest.in
===
--- lldb/utils/lldb-dotest/lldb-dotest.in
+++ lldb/utils/lldb-dotest/lldb-dotest.in
@@ -8,7 +8,6 @@
 executable = '@LLDB_TEST_EXECUTABLE_CONFIGURED@'
 compiler = '@LLDB_TEST_COMPILER_CONFIGURED@'
 dsymutil = '@LLDB_TEST_DSYMUTIL_CONFIGURED@'
-server = '@LLDB_TEST_SERVER_CONFIGURED@'
 lldb_build_dir = '@LLDB_TEST_BUILD_DIRECTORY_CONFIGURED@'
 lldb_build_intel_pt = "@LLDB_BUILD_INTEL_PT@"
 lldb_framework_dir = "@LLDB_FRAMEWORK_DIR_CONFIGURED@"
@@ -28,8 +27,6 @@
 cmd.extend(['--dsymutil', dsymutil])
 cmd.extend(['--lldb-libs-dir', lldb_libs_dir])
 cmd.extend(['--llvm-tools-dir', llvm_tools_dir])
-if server:
-cmd.extend(['--server', server])
 if lldb_framework_dir:
 cmd.extend(['--framework', lldb_framework_dir])
 if lldb_build_intel_pt == "1":
Index: lldb/utils/lldb-dotest/CMakeLists.txt
===
--- lldb/utils/lldb-dotest/CMakeLists.txt
+++ lldb/utils/lldb-dotest/CMakeLists.txt
@@ -19,7 +19,6 @@
   LLDB_TEST_EXECUTABLE
   LLDB_TEST_COMPILER
   LLDB_TEST_DSYMUTIL
-  LLDB_TEST_SERVER
   LLDB_LIBS_DIR
   LLVM_TOOLS_DIR
   )
Index: lldb/test/API/lit.site.cfg.py.in
===
--- lldb/test/API/lit.site.cfg.py.in
+++ lldb/test/API/lit.site.cfg.py.in
@@ -29,7 +29,6 @@
 config.test_arch = '@LLDB_TEST_ARCH@'
 config.test_compiler = '@LLDB_TEST_COMPILER@'
 config.dsymutil = '@LLDB_TEST_DSYMUTIL@'
-config.server = '@LLDB_TEST_SERVER@'
 # The API tests use their own module caches.
 config.lldb_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_LLDB@", "lldb-api")
 config.clang_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_CLANG@", "lldb-api")
@@ -55,7 +54,6 @@
 config.lldb_executable = config.lldb_executable % lit_config.params
 config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
 config.test_compiler = config.test_compiler % lit_config.params
-config.server = config.server % lit_config.params
 config.lldb_framework_dir = config.lldb_framework_dir % lit_config.params
 config.dotest_args_str = config.dotest_args_str % lit_config.params
 except KeyError as e:
Index: lldb/test/API/commands/platform/sdk/TestPlatformSDK.py
===
--- lldb/test/API/commands/platform/sdk/TestPlatformSDK.py
+++ lldb/test/API/commands/platform/sdk/TestPlatformSDK.py
@@ -3,6 +3,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
+from lldbgdbserverutils import get_debugserver_exe
 
 import os
 import platform
@@ -28,7 +29,7 @@
 TIMEOUT = 2
 
 def no_debugserver(self):
-if os.getenv('LLDB_DEBUGSERVER_PATH') is None:
+if get_debugserver_exe() is None:
 return 'no debugserver'
 return None
 
@@ -88,7 +89,7 @@
 shutil.move(exe, exe_sdk_path)
 
 # Attach to it with debugserver.
-debugserver = os.getenv('LLDB_DEBUGSERVER_PATH')
+debugserver = get_debugserver_exe()
 debugserver_args = [
 'localho

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-06 Thread Michał Górny via Phabricator via lldb-commits 
mgorny added a comment.

In D95802#2546786 , @labath wrote:

> It doesn't look //too// bad, but what's up with the `friend` thingy? What's 
> that used for? Can we get rid of it?

It's needed to access `SetSoftwareBreakpoint()`, though I'm not really sure why 
that method is not public. Maybe it'd be better to mark it public instead.


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

https://reviews.llvm.org/D95802

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

[Lldb-commits] [PATCH] D96201: [nfc] [lldb] Add Dwo assert

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

Hm... I'm not sure about that... I mean, there's not much use for it, and we 
probably aren't doing anything like that right now, but I don't see anything 
inherently wrong about querying a skeleton unit for a DIE (even though it 
should only contain the root die).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96201

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

[Lldb-commits] [PATCH] D96202: [lldb/test] Automatically find debug servers to test

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py:75-79
-if "LLDB_DEBUGSERVER_PATH" in os.environ:
-return os.environ["LLDB_DEBUGSERVER_PATH"]
 
-return _get_debug_monitor_from_lldb(
-lldbtest_config.lldbExec, "lldb-server")

@rupprecht : I'm adding you mainly because my last attempt to change this 
function broke some google integration stuff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96202

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

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-06 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

In D95802#2546809 , @mgorny wrote:

> In D95802#2546786 , @labath wrote:
>
>> It doesn't look //too// bad, but what's up with the `friend` thingy? What's 
>> that used for? Can we get rid of it?
>
> It's needed to access `SetSoftwareBreakpoint()`, though I'm not really sure 
> why that method is not public. Maybe it'd be better to mark it public instead.

The public interface is `SetBreakpoint(..., hardware=false)`, though I can't 
say I am particularly fond it...


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

https://reviews.llvm.org/D95802

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

[Lldb-commits] [lldb] 3cc3762 - [lldb] Use assertIn/NotIn over assertTrue/False (NFC)

2021-02-06 Thread Dave Lee via lldb-commits 

Author: Dave Lee
Date: 2021-02-06T11:52:01-08:00
New Revision: 3cc37622921f39e4bdad7a37b7199defa58a213a

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

LOG: [lldb] Use assertIn/NotIn over assertTrue/False (NFC)

For improved failure messages, use `assertIn` over `assertTrue`.

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

Added: 


Modified: 
lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py
lldb/test/API/commands/frame/var/TestFrameVar.py

lldb/test/API/functionalities/breakpoint/breakpoint_names/TestBreakpointNames.py
lldb/test/API/functionalities/breakpoint/debugbreak/TestDebugBreak.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/queue/TestDataFormatterLibcxxQueue.py
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
lldb/test/API/functionalities/history/TestHistoryRecall.py

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
lldb/test/API/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
lldb/test/API/functionalities/postmortem/minidump/TestMiniDump.py
lldb/test/API/functionalities/process_save_core/TestProcessSaveCore.py
lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
lldb/test/API/functionalities/step_scripted/TestStepScripted.py

lldb/test/API/functionalities/tail_call_frames/cross_dso/TestCrossDSOTailCalls.py

lldb/test/API/functionalities/tail_call_frames/cross_object/TestCrossObjectTailCalls.py

lldb/test/API/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
lldb/test/API/functionalities/tsan/basic/TestTsanBasic.py
lldb/test/API/functionalities/ubsan/basic/TestUbsanBasic.py
lldb/test/API/lang/c/vla/TestVLA.py
lldb/test/API/lang/cpp/accelerator-table/TestCPPAccelerator.py
lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
lldb/test/API/lang/cpp/class_types/TestClassTypes.py

lldb/test/API/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py
lldb/test/API/lang/objc/exceptions/TestObjCExceptions.py
lldb/test/API/lang/objc/objc-checker/TestObjCCheckers.py
lldb/test/API/macosx/macCatalyst/TestMacCatalyst.py

lldb/test/API/macosx/macCatalystAppMacOSFramework/TestMacCatalystAppWithMacOSFramework.py
lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
lldb/test/API/tools/lldb-server/TestGdbRemoteAuxvSupport.py
lldb/test/API/tools/lldb-server/TestGdbRemoteExpeditedRegisters.py
lldb/test/API/tools/lldb-server/TestGdbRemoteHostInfo.py
lldb/test/API/tools/lldb-server/TestGdbRemote_vCont.py
lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
lldb/test/API/tools/lldb-vscode/console/TestVSCode_console.py
lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py

Removed: 




diff  --git a/lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py 
b/lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py
index 083d97adf1b2..ab1438479aab 100644
--- a/lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py
+++ b/lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py
@@ -69,7 +69,7 @@ def expr_options_test(self):
 # Again use it and ensure we fail:
 result = frame.EvaluateExpression("call_me(10)", options)
 self.assertTrue(result.GetError().Fail(), "expression failed with no 
JIT")
-self.assertTrue("Can't evaluate the expression without a running 
target" in result.GetError().GetCString(), "Got right error")
+self.assertIn("Can't evaluate the expression without a running 
target", result.GetError().GetCString(), "Got right error")
 
 # Finally set the allow JIT value back to true and make sure that 
works:
 options.SetAllowJIT(True)

diff  --git a/lldb/test/API/commands/frame/var/TestFrameVar.py 
b/lldb/test/API/commands/frame/var/TestFrameVar.py
index 0e053eb945dd..6b67e41ab74c 100644
--- a/lldb/test/API/commands/frame/var/TestFrameVar.py
+++ b/lldb/test/API/commands/frame/var/TestFrameVar.py
@@ -64,28 +64,28 @@ def do_test(self):
 result = interp.HandleCommand("frame var -l", command_result)
 self.assertEqual(result, lldb.eReturnStatusSuccessFinishResult, "frame 
var -a didn't succeed")
 output = command_result.GetOutput()
-self.assertTrue("argc" in output, "Args didn't find argc")
-self.assertTrue("argv" in output, "Args didn't find argv")
-self.a

[Lldb-commits] [PATCH] D96095: [lldb] Use assertIn/NotIn over assertTrue/False (NFC)

2021-02-06 Thread Dave Lee 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 rG3cc37622921f: [lldb] Use assertIn/NotIn over 
assertTrue/False (NFC) (authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96095

Files:
  lldb/test/API/commands/expression/dont_allow_jit/TestAllowJIT.py
  lldb/test/API/commands/frame/var/TestFrameVar.py
  
lldb/test/API/functionalities/breakpoint/breakpoint_names/TestBreakpointNames.py
  lldb/test/API/functionalities/breakpoint/debugbreak/TestDebugBreak.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/queue/TestDataFormatterLibcxxQueue.py
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
  lldb/test/API/functionalities/history/TestHistoryRecall.py
  
lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
  lldb/test/API/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
  lldb/test/API/functionalities/postmortem/minidump/TestMiniDump.py
  lldb/test/API/functionalities/process_save_core/TestProcessSaveCore.py
  lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
  lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py
  lldb/test/API/functionalities/step_scripted/TestStepScripted.py
  
lldb/test/API/functionalities/tail_call_frames/cross_dso/TestCrossDSOTailCalls.py
  
lldb/test/API/functionalities/tail_call_frames/cross_object/TestCrossObjectTailCalls.py
  
lldb/test/API/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
  lldb/test/API/functionalities/tsan/basic/TestTsanBasic.py
  lldb/test/API/functionalities/ubsan/basic/TestUbsanBasic.py
  lldb/test/API/lang/c/vla/TestVLA.py
  lldb/test/API/lang/cpp/accelerator-table/TestCPPAccelerator.py
  lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
  lldb/test/API/lang/cpp/class_types/TestClassTypes.py
  lldb/test/API/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py
  lldb/test/API/lang/objc/exceptions/TestObjCExceptions.py
  lldb/test/API/lang/objc/objc-checker/TestObjCCheckers.py
  lldb/test/API/macosx/macCatalyst/TestMacCatalyst.py
  
lldb/test/API/macosx/macCatalystAppMacOSFramework/TestMacCatalystAppWithMacOSFramework.py
  lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteExpeditedRegisters.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteHostInfo.py
  lldb/test/API/tools/lldb-server/TestGdbRemote_vCont.py
  lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
  lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
  lldb/test/API/tools/lldb-vscode/console/TestVSCode_console.py
  lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
  lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
  lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py

Index: lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
===
--- lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -69,8 +69,8 @@
 def verify_variables(self, verify_dict, variables, varref_dict=None):
 for variable in variables:
 name = variable['name']
-self.assertTrue(name in verify_dict,
-'variable "%s" in verify dictionary' % (name))
+self.assertIn(name, verify_dict,
+  'variable "%s" in verify dictionary' % (name))
 self.verify_values(verify_dict[name], variable, varref_dict)
 
 @skipIfWindows
Index: lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
===
--- lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
+++ lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
@@ -31,7 +31,7 @@
 self.assertEqual(program_basename, program_module['name'])
 self.assertIn('path', program_module, 'make sure path is in module')
 self.assertEqual(program, program_module['path'])
-self.assertTrue('symbolFilePath' not in program_module, 'Make sure a.out.stripped has no debug info')
+self.assertNotIn('symbolFilePath', program_module, 'Make sure a.out.stripped has no debug info')
 symbols_path = self.getBuildArtifact(symbol_basename)
 self.vscode.request_evaluate('`%s' % ('target symbols add -s "%s" "%s"' % (program, symbols_path)))
 
Index: lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
===
--- lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
+++ lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.p

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-06 Thread Michał Górny via Phabricator via lldb-commits 
mgorny updated this revision to Diff 321966.
mgorny edited the summary of this revision.
mgorny added a comment.
Herald added a subscriber: arichardson.

Fixed breakpoints and FPR reading. Now it's actually tested ;-).


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

https://reviews.llvm.org/D95947

Files:
  lldb/source/Host/common/NativeProcessProtocol.cpp
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_powerpc.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_powerpc.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_powerpc.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -19,7 +19,9 @@
 
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
+#include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterContextPOSIX_powerpc.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 #include "Plugins/Process/Utility/lldb-arm-register-enums.h"
@@ -458,3 +460,95 @@
 }
 
 #endif // defined(__mips64__)
+
+#if defined(__powerpc__)
+
+#define EXPECT_GPR_PPC(lldb_reg, fbsd_reg)\
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_powerpc),  \
+  ::testing::Pair(offsetof(reg, fbsd_reg),   \
+  sizeof(reg::fbsd_reg)))
+#define EXPECT_FPU_PPC(lldb_reg, fbsd_reg)   \
+  EXPECT_THAT(GetRegParams(reg_ctx, fpr_##lldb_reg##_powerpc),   \
+  ::testing::Pair(offsetof(fpreg, fbsd_reg) + base_offset, \
+  sizeof(fpreg::fbsd_reg)))
+
+TEST(RegisterContextFreeBSDTest, powerpc32) {
+  ArchSpec arch{"powerpc-unknown-freebsd"};
+  RegisterContextFreeBSD_powerpc32 reg_ctx{arch};
+
+  EXPECT_GPR_PPC(r0, fixreg[0]);
+  EXPECT_GPR_PPC(r1, fixreg[1]);
+  EXPECT_GPR_PPC(r2, fixreg[2]);
+  EXPECT_GPR_PPC(r3, fixreg[3]);
+  EXPECT_GPR_PPC(r4, fixreg[4]);
+  EXPECT_GPR_PPC(r5, fixreg[5]);
+  EXPECT_GPR_PPC(r6, fixreg[6]);
+  EXPECT_GPR_PPC(r7, fixreg[7]);
+  EXPECT_GPR_PPC(r8, fixreg[8]);
+  EXPECT_GPR_PPC(r9, fixreg[9]);
+  EXPECT_GPR_PPC(r10, fixreg[10]);
+  EXPECT_GPR_PPC(r11, fixreg[11]);
+  EXPECT_GPR_PPC(r12, fixreg[12]);
+  EXPECT_GPR_PPC(r13, fixreg[13]);
+  EXPECT_GPR_PPC(r14, fixreg[14]);
+  EXPECT_GPR_PPC(r15, fixreg[15]);
+  EXPECT_GPR_PPC(r16, fixreg[16]);
+  EXPECT_GPR_PPC(r17, fixreg[17]);
+  EXPECT_GPR_PPC(r18, fixreg[18]);
+  EXPECT_GPR_PPC(r19, fixreg[19]);
+  EXPECT_GPR_PPC(r20, fixreg[20]);
+  EXPECT_GPR_PPC(r21, fixreg[21]);
+  EXPECT_GPR_PPC(r22, fixreg[22]);
+  EXPECT_GPR_PPC(r23, fixreg[23]);
+  EXPECT_GPR_PPC(r24, fixreg[24]);
+  EXPECT_GPR_PPC(r25, fixreg[25]);
+  EXPECT_GPR_PPC(r26, fixreg[26]);
+  EXPECT_GPR_PPC(r27, fixreg[27]);
+  EXPECT_GPR_PPC(r28, fixreg[28]);
+  EXPECT_GPR_PPC(r29, fixreg[29]);
+  EXPECT_GPR_PPC(r30, fixreg[30]);
+  EXPECT_GPR_PPC(r31, fixreg[31]);
+  EXPECT_GPR_PPC(lr, lr);
+  EXPECT_GPR_PPC(cr, cr);
+  EXPECT_GPR_PPC(xer, xer);
+  EXPECT_GPR_PPC(ctr, ctr);
+  EXPECT_GPR_PPC(pc, pc);
+
+  size_t base_offset = reg_ctx.GetRegisterInfo()[fpr_f0_powerpc].byte_offset;
+
+  EXPECT_FPU_PPC(f0, fpreg[0]);
+  EXPECT_FPU_PPC(f1, fpreg[1]);
+  EXPECT_FPU_PPC(f2, fpreg[2]);
+  EXPECT_FPU_PPC(f3, fpreg[3]);
+  EXPECT_FPU_PPC(f4, fpreg[4]);
+  EXPECT_FPU_PPC(f5, fpreg[5]);
+  EXPECT_FPU_PPC(f6, fpreg[6]);
+  EXPECT_FPU_PPC(f7, fpreg[7]);
+  EXPECT_FPU_PPC(f8, fpreg[8]);
+  EXPECT_FPU_PPC(f9, fpreg[9]);
+  EXPECT_FPU_PPC(f10, fpreg[10]);
+  EXPECT_FPU_PPC(f11, fpreg[11]);
+  EXPECT_FPU_PPC(f12, fpreg[12]);
+  EXPECT_FPU_PPC(f13, fpreg[13]);
+  EXPECT_FPU_PPC(f14, fpreg[14]);
+  EXPECT_FPU_PPC(f15, fpreg[15]);
+  EXPECT_FPU_PPC(f16, fpreg[16]);
+  EXPECT_FPU_PPC(f17, fpreg[17]);
+  EXPECT_FPU_PPC(f18, fpreg[18]);
+  EXPECT_FPU_PPC(f19, fpreg[19]);
+  EXPECT_FPU_PPC(f20, fpreg[20]);
+  EXPECT_FPU_PPC(f21, fpreg[21]);
+  EXPECT_FPU_PPC(f22, fpreg[22]);
+  EXPECT_FPU_PPC(f23, fpreg[23]);
+  EXPECT_FPU_PPC(f24, fpreg[24]);
+  EXPECT_FPU_PPC(f25, fpreg[25]);
+  EXPECT_FPU_PPC(f26, fpreg[26]);
+  EXPECT_FPU_PPC(f27, fpreg[27]);
+  EXPECT_FPU_PPC(f28, fpreg[28]);
+  EXPECT_FPU_PPC(f29, fpreg[29]);
+  EXPECT_FPU_PPC(f30, fpreg[30]);
+  EXPECT_FPU_PPC(f31, fpreg[31]);
+  EXPECT_FPU_PPC(fpscr, fpscr);
+}
+
+#endif // defined(__powerpc__)
Index: lldb/source/Plugins/Process/Utility/Reg