[Lldb-commits] [PATCH] D129703: [lldb] Refactor command option enum values (NFC)

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
JDevlieghere marked an inline comment as done.
Closed by commit rG7ced9fff9547: [lldb] Refactor command option enum values 
(NFC) (authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129703

Files:
  lldb/include/lldb/Interpreter/CommandObject.h
  lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
  lldb/include/lldb/Target/Target.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/include/lldb/lldb-private-enumerations.h
  lldb/source/Commands/CMakeLists.txt
  lldb/source/Commands/CommandObjectBreakpoint.cpp
  lldb/source/Commands/CommandObjectBreakpointCommand.cpp
  lldb/source/Commands/CommandObjectCommands.cpp
  lldb/source/Commands/CommandObjectDisassemble.cpp
  lldb/source/Commands/CommandObjectExpression.cpp
  lldb/source/Commands/CommandObjectFrame.cpp
  lldb/source/Commands/CommandObjectHelp.cpp
  lldb/source/Commands/CommandObjectLog.cpp
  lldb/source/Commands/CommandObjectMemory.cpp
  lldb/source/Commands/CommandObjectMemoryTag.cpp
  lldb/source/Commands/CommandObjectPlatform.cpp
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/CommandObjectRegister.cpp
  lldb/source/Commands/CommandObjectReproducer.cpp
  lldb/source/Commands/CommandObjectScript.cpp
  lldb/source/Commands/CommandObjectSession.cpp
  lldb/source/Commands/CommandObjectSettings.cpp
  lldb/source/Commands/CommandObjectSource.cpp
  lldb/source/Commands/CommandObjectStats.cpp
  lldb/source/Commands/CommandObjectTarget.cpp
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/CommandObjectTrace.cpp
  lldb/source/Commands/CommandObjectType.cpp
  lldb/source/Commands/CommandObjectWatchpoint.cpp
  lldb/source/Commands/CommandObjectWatchpointCommand.cpp
  lldb/source/Commands/CommandOptionArgumentTable.cpp
  lldb/source/Commands/CommandOptionsProcessLaunch.cpp
  lldb/source/Commands/Options.td
  lldb/source/Commands/OptionsBase.td
  lldb/source/Interpreter/CommandObject.cpp
  lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
  lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.cpp
  lldb/utils/TableGen/LLDBOptionDefEmitter.cpp

Index: lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
===
--- lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
+++ lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
@@ -31,7 +31,6 @@
   std::string ArgType;
   bool OptionalArg = false;
   std::string Validator;
-  std::string ArgEnum;
   std::vector Completions;
   std::string Description;
 
@@ -65,9 +64,6 @@
 if (Option->getValue("Validator"))
   Validator = std::string(Option->getValueAsString("Validator"));
 
-if (Option->getValue("ArgEnum"))
-  ArgEnum = std::string(Option->getValueAsString("ArgEnum"));
-
 if (Option->getValue("Completions"))
   Completions = Option->getValueAsListOfStrings("Completions");
 
@@ -114,8 +110,8 @@
 OS << "nullptr";
   OS << ", ";
 
-  if (!O.ArgEnum.empty())
-OS << O.ArgEnum;
+  if (!O.ArgType.empty())
+OS << "g_argument_table[eArgType" << O.ArgType << "].enum_values";
   else
 OS << "{}";
   OS << ", ";
Index: lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.cpp
===
--- lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.cpp
+++ lldb/source/Plugins/TraceExporter/ctf/CommandObjectThreadTraceExportCTF.cpp
@@ -10,6 +10,7 @@
 
 #include "../common/TraceHTR.h"
 #include "lldb/Host/OptionParser.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/Trace.h"
 
Index: lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
===
--- lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
+++ lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
@@ -11,6 +11,7 @@
 #include "TraceIntelPT.h"
 #include "TraceIntelPTConstants.h"
 #include "lldb/Host/OptionParser.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/Trace.h"
 
Index: lldb/source/Interpreter/CommandObject.cpp
===
--- lldb/source/Interpreter/CommandObject.cpp
+++ lldb/source/Interpreter/CommandObject.cpp
@@ -31,6 +31,7 @@
 #include "lldb/Target/Language.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
 
 using namespace lldb;
@@ -365,19 +366,16 @@
 
 const CommandObject::ArgumentTableEntry *
 CommandObject::FindArgumentDataByType(CommandArgumentType arg_type) {
-  const ArgumentTableEntry 

[Lldb-commits] [PATCH] D129707: [lldb] Print the enum values and their description in the argument value help output

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbcae3cdbd029: [lldb] Print the enum values and their 
description in the help output (authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129707

Files:
  lldb/source/Interpreter/CommandObject.cpp
  lldb/test/API/commands/help/TestHelp.py


Index: lldb/test/API/commands/help/TestHelp.py
===
--- lldb/test/API/commands/help/TestHelp.py
+++ lldb/test/API/commands/help/TestHelp.py
@@ -318,3 +318,16 @@
 "\(does not apply to binary output\)."])
 self.expect("help memory find", patterns=[
 "--show-tags\n\s+Include memory tags in output."])
+
+@no_debug_info_test
+def test_help_show_enum_values(self):
+""" Check the help output for a argument type contains the enum values
+and their descriptions. """
+self.expect("help ", substrs=[
+'The log handle that will be used to write out log messages.',
+'default'  , 'Use the default (stream) log handler',
+'stream'   , 'Write log messages to the debugger output stream',
+'circular' , 'Write log messages to a fixed size circular buffer',
+'os'   , 'Write log messages to the operating system log',
+])
+
Index: lldb/source/Interpreter/CommandObject.cpp
===
--- lldb/source/Interpreter/CommandObject.cpp
+++ lldb/source/Interpreter/CommandObject.cpp
@@ -16,6 +16,7 @@
 #include 
 
 #include "lldb/Core/Address.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Interpreter/Options.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "llvm/ADT/ScopeExit.h"
@@ -398,9 +399,28 @@
   interpreter.OutputHelpText(str, name_str.GetString(), "--", help_text,
  name_str.GetSize());
 }
-  } else
+  } else {
 interpreter.OutputFormattedHelpText(str, name_str.GetString(), "--",
 entry->help_text, name_str.GetSize());
+
+// Print enum values and their description if any.
+OptionEnumValues enum_values = g_argument_table[arg_type].enum_values;
+if (!enum_values.empty()) {
+  str.EOL();
+  size_t longest = 0;
+  for (const OptionEnumValueElement  : enum_values)
+longest =
+std::max(longest, llvm::StringRef(element.string_value).size());
+  str.IndentMore(5);
+  for (const OptionEnumValueElement  : enum_values) {
+str.Indent();
+interpreter.OutputHelpText(str, element.string_value, ":",
+   element.usage, longest);
+  }
+  str.IndentLess(5);
+  str.EOL();
+}
+  }
 }
 
 const char *CommandObject::GetArgumentName(CommandArgumentType arg_type) {


Index: lldb/test/API/commands/help/TestHelp.py
===
--- lldb/test/API/commands/help/TestHelp.py
+++ lldb/test/API/commands/help/TestHelp.py
@@ -318,3 +318,16 @@
 "\(does not apply to binary output\)."])
 self.expect("help memory find", patterns=[
 "--show-tags\n\s+Include memory tags in output."])
+
+@no_debug_info_test
+def test_help_show_enum_values(self):
+""" Check the help output for a argument type contains the enum values
+and their descriptions. """
+self.expect("help ", substrs=[
+'The log handle that will be used to write out log messages.',
+'default'  , 'Use the default (stream) log handler',
+'stream'   , 'Write log messages to the debugger output stream',
+'circular' , 'Write log messages to a fixed size circular buffer',
+'os'   , 'Write log messages to the operating system log',
+])
+
Index: lldb/source/Interpreter/CommandObject.cpp
===
--- lldb/source/Interpreter/CommandObject.cpp
+++ lldb/source/Interpreter/CommandObject.cpp
@@ -16,6 +16,7 @@
 #include 
 
 #include "lldb/Core/Address.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Interpreter/Options.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "llvm/ADT/ScopeExit.h"
@@ -398,9 +399,28 @@
   interpreter.OutputHelpText(str, name_str.GetString(), "--", help_text,
  name_str.GetSize());
 }
-  } else
+  } else {
 interpreter.OutputFormattedHelpText(str, name_str.GetString(), "--",
 entry->help_text, name_str.GetSize());
+
+// Print enum values and their description if any.
+OptionEnumValues enum_values = g_argument_table[arg_type].enum_values;
+if (!enum_values.empty()) {
+

[Lldb-commits] [lldb] bcae3cd - [lldb] Print the enum values and their description in the help output

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2022-07-14T21:18:08-07:00
New Revision: bcae3cdbd029210e9ecf42f07d38cc4ed4a95230

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

LOG: [lldb] Print the enum values and their description in the help output

Print the enum values and their description in the help output for
argument values. Until now, there was no way to get these values and
their description.

Example output:

(lldb) help 
   -- How verbose the output of 'po' should be.

 compact : Only show the description string
 full: Show the full output, including persistent variable's
   name and type

Differential revision: https://reviews.llvm.org/D129707

Added: 


Modified: 
lldb/source/Interpreter/CommandObject.cpp
lldb/test/API/commands/help/TestHelp.py

Removed: 




diff  --git a/lldb/source/Interpreter/CommandObject.cpp 
b/lldb/source/Interpreter/CommandObject.cpp
index 609ac57e2ac16..719cfbc9e8023 100644
--- a/lldb/source/Interpreter/CommandObject.cpp
+++ b/lldb/source/Interpreter/CommandObject.cpp
@@ -16,6 +16,7 @@
 #include 
 
 #include "lldb/Core/Address.h"
+#include "lldb/Interpreter/CommandOptionArgumentTable.h"
 #include "lldb/Interpreter/Options.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "llvm/ADT/ScopeExit.h"
@@ -398,9 +399,28 @@ void CommandObject::GetArgumentHelp(Stream , 
CommandArgumentType arg_type,
   interpreter.OutputHelpText(str, name_str.GetString(), "--", help_text,
  name_str.GetSize());
 }
-  } else
+  } else {
 interpreter.OutputFormattedHelpText(str, name_str.GetString(), "--",
 entry->help_text, name_str.GetSize());
+
+// Print enum values and their description if any.
+OptionEnumValues enum_values = g_argument_table[arg_type].enum_values;
+if (!enum_values.empty()) {
+  str.EOL();
+  size_t longest = 0;
+  for (const OptionEnumValueElement  : enum_values)
+longest =
+std::max(longest, llvm::StringRef(element.string_value).size());
+  str.IndentMore(5);
+  for (const OptionEnumValueElement  : enum_values) {
+str.Indent();
+interpreter.OutputHelpText(str, element.string_value, ":",
+   element.usage, longest);
+  }
+  str.IndentLess(5);
+  str.EOL();
+}
+  }
 }
 
 const char *CommandObject::GetArgumentName(CommandArgumentType arg_type) {

diff  --git a/lldb/test/API/commands/help/TestHelp.py 
b/lldb/test/API/commands/help/TestHelp.py
index 6e0cfe4326636..7d19665498568 100644
--- a/lldb/test/API/commands/help/TestHelp.py
+++ b/lldb/test/API/commands/help/TestHelp.py
@@ -318,3 +318,16 @@ def test_help_show_tags(self):
 "\(does not apply to binary output\)."])
 self.expect("help memory find", patterns=[
 "--show-tags\n\s+Include memory tags in output."])
+
+@no_debug_info_test
+def test_help_show_enum_values(self):
+""" Check the help output for a argument type contains the enum values
+and their descriptions. """
+self.expect("help ", substrs=[
+'The log handle that will be used to write out log messages.',
+'default'  , 'Use the default (stream) log handler',
+'stream'   , 'Write log messages to the debugger output stream',
+'circular' , 'Write log messages to a fixed size circular buffer',
+'os'   , 'Write log messages to the operating system log',
+])
+



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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a subscriber: teemperor.
JDevlieghere added a comment.

In D112374#3653702 , @mizvekov wrote:

> @JDevlieghere I spent a lot of time trying to get this test running on my 
> machine to no avail. I think lldb build and test setup is quite convoluted, 
> fragile and antiquated. It uses many deprecated CMake features, It fails to 
> properly link to system libraries it needs like librt. And I just kept 
> patching these problems up and more kept coming. At some point I just gave up.

I'm sorry to hear you're having trouble building LLDB. The LLDB website has 
quite an elaborate guide with instructions in how to build LLDB: 
https://lldb.llvm.org/resources/build.html, including specific instructions on 
Windows. Windows is not my main platform, but I've successfully built LLDB 
there in the past following those instructions. I'm not sure what you feel is 
"convoluted, fragile and antiquated" about our build and test setup, as it's 
fairly similar to the rest of LLVM. I'd be happy to hear your suggestions on 
how we could improve things.

> And even this test itself requires the whole libcxx it seems, which is 
> another difficult thing to get building outside of CI.
>
> I think pre-commit CI is essential here.
>
> So I would be happy to help sort this lldb bug, but you have to help me help 
> you.

I'm happy to help out. I personally don't know if we should go with (1) or (2), 
both sound reasonable in their own way. I'd like @teemperor, who's the author 
of the feature and the affected tests, to weigh in.

> I think reverting it with no prior notification was unreasonable, and landing 
> this back as it was, no changes, is reasonable.
>
> Do you agree? Please let me know soon otherwise.

I don't. I think reverting your change was well within the guidelines outlined 
by LLVM's patch reversion policy: 
https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Additionally, I think you could've given me a little bit more time to catch up 
on the discussion here. The code review policy and practices 
(https://llvm.org/docs/CodeReview.html#code-reviews-speed-and-reciprocity) 
recommend pinging every few days to once per week depending on how urgent the 
patch is.

By relanding, you broke the bots again 
(https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45354/#showFailuresLink)
 and I'm forced to revert this change a second time. Please refrain from 
landing this again until we've settled on a way forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[NAKAMURA Takumi via Phabricator via lldb-commits]

chapuni added inline comments.



Comment at: clang/lib/Sema/TypeLocBuilder.cpp:159
 
-  assert(Capacity - Index == TypeLoc::getFullDataSizeForType(T) &&
+  unsigned FDSz = TypeLoc::getFullDataSizeForType(T);
+  assert(Capacity - Index == FDSz &&

It causes a warning with -Asserts. May be rolled back.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Matheus Izvekov via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7c51f02effdb: [clang] Implement ElaboratedType sugaring for 
types written bare (authored by mizvekov).

Changed prior to commit:
  https://reviews.llvm.org/D112374?vs=444113=444856#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

Files:
  clang-tools-extra/clang-change-namespace/ChangeNamespace.cpp
  clang-tools-extra/clang-include-fixer/find-all-symbols/FindAllSymbols.cpp
  clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SmartPtrArrayMismatchCheck.cpp
  clang-tools-extra/clang-tidy/google/AvoidCStyleCastsCheck.cpp
  clang-tools-extra/clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tools-extra/clang-tidy/misc/MisplacedConstCheck.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clang-tidy/modernize/PassByValueCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseTrailingReturnTypeCheck.cpp
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/unittests/ASTTests.cpp
  clang-tools-extra/clangd/unittests/DumpASTTests.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone/copy-constructor-init.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/shared-ptr-array-mismatch.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-memory-comparison-32bits.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/suspicious-memory-comparison.cpp
  clang-tools-extra/test/clang-tidy/checkers/readability/const-return-type.cpp
  clang-tools-extra/unittests/clang-change-namespace/ChangeNamespaceTests.cpp
  clang/bindings/python/tests/cindex/test_type.py
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/lib/ARCMigrate/ObjCMT.cpp
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTDiagnostic.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/FormatString.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/QualTypeNames.cpp
  clang/lib/AST/ScanfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Analysis/RetainSummaryManager.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Sema/TypeLocBuilder.cpp
  clang/lib/Sema/TypeLocBuilder.h
  clang/lib/StaticAnalyzer/Checkers/NonnullGlobalConstantsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/NumberObjectConversionChecker.cpp
  clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
  clang/test/AST/ast-dump-APValue-anon-union.cpp
  clang/test/AST/ast-dump-APValue-struct.cpp
  clang/test/AST/ast-dump-APValue-union.cpp
  clang/test/AST/ast-dump-decl.cpp
  clang/test/AST/ast-dump-expr-json.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/AST/ast-dump-funcs.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_template_3.cpp
  clang/test/AST/ast-dump-overloaded-operators.cpp
  clang/test/AST/ast-dump-records-json.cpp
  clang/test/AST/ast-dump-recovery.cpp
  clang/test/AST/ast-dump-stmt-json.cpp
  clang/test/AST/ast-dump-stmt.cpp
  clang/test/AST/ast-dump-template-decls-json.cpp
  clang/test/AST/ast-dump-temporaries-json.cpp
  clang/test/AST/ast-dump-using-template.cpp
  clang/test/AST/ast-dump-using.cpp
  clang/test/AST/coroutine-locals-cleanup-exp-namespace.cpp
  clang/test/AST/coroutine-locals-cleanup.cpp
  clang/test/AST/float16.cpp
  clang/test/AST/sourceranges.cpp
  clang/test/Analysis/Inputs/expected-plists/NewDelete-path-notes.cpp.plist
  clang/test/Analysis/Inputs/expected-plists/cxx-for-range.cpp.plist
  clang/test/Analysis/Inputs/expected-plists/method-call-path-notes.cpp.plist
  clang/test/Analysis/analyzer-display-progress.cpp
  clang/test/Analysis/auto-obj-dtors-cfg-output.cpp
  clang/test/Analysis/blocks.mm
  clang/test/Analysis/bug_hash_test.cpp
  clang/test/Analysis/cast-value-notes.cpp
  clang/test/Analysis/cast-value-state-dump.cpp
  clang/test/Analysis/cfg-rich-constructors.cpp
  clang/test/Analysis/cfg-rich-constructors.mm
  clang/test/Analysis/cfg.cpp
  clang/test/Analysis/copy-elision.cpp
  clang/test/Analysis/cxx-uninitialized-object-inheritance.cpp
  

[Lldb-commits] [PATCH] D129682: [lldb] Filter DIEs based on qualified name when possible

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

BTW, this is a side comment, but given that it's fairly common in the STL at 
least to have functions with a bevy of defaulted arguments that very few people 
specify or even really know are part of the function signature, it would be 
neat to do things like:

(lldb) break set -n foo::bar::baz(int, *)

or something, meaning, first argument is an int, I don't care about the others.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129682

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

[Lldb-commits] [PATCH] D129682: [lldb] Filter DIEs based on qualified name when possible

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

It always bugged me that `break set some::long::path::a_common_word` was going 
to realize all the debug info for functions called "a_common_word".  In large 
projects there can be a lot of those.  So I'm not 100% surprised that this 
gives us a good speedup (but happy!)

I certainly don't want us to give up on setting breakpoints by overload as well 
as function name.  This is currently inconvenient because we don't have a 
"fuzzy argument matcher", instead you have to type the arguments exactly as the 
demangler would.  That shouldn't be all that hard to implement, and even 
without that it's a fairly useful feature when you've got lots of overloads.  
The alternative, setting the breakpoint on the name and then disabling the 
overloads you don't want, is tedious and makes us look a little weak...

I'm not familiar enough with the DWARF parser to make useful comments on that 
part of the change, but the rest looks fine, and this is a great idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129682

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

[Lldb-commits] [PATCH] D129521: Add the ability to run expressions that call fork() or vfork().

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

First off, I think making "follows-fork=child" work in expressions will be 
pretty tricky at present, since lldb can only control either the parent or the 
child.  But you have to make sure the parent side of the expression completes, 
so you can't let go of the parent right away.  You'll have to let the parent 
run a bit more before you can switch over to the child.  You either need to 
suspend the child while doing that (which may cause the parent side of the 
forked expression not to complete) or deal with the fact that the child might 
not survive the expression, and you're left with nothing to switch over to.  
That seems messy.

If we get to the point where instead of replacing the parent with the child we 
create another Target/Process for the child, then dealing with the fork would 
be pretty straightforward.  You would temporarily force "follows-fork=both".  
The function call plan would not explain the fork stop, the event would proceed 
to whoever does the fork following, it would create an new Target/Process for 
the child, and then letting both run will complete the expression with a live 
child to cooperate in that process.  Then if the follows-fork mode was actually 
"child" you would just discard the first Target/Process, and switch to the new 
one.

So I'd defer the feature of "follows-fork=child in expressions" till we are 
doing it that way, and for now just document that follows-fork does NOT pertain 
to forks created by running expressions.

If that seems right, then for now you want to just ensure that the vfork is 
allowed to continue while lldb follows the parent.  In that case, this isn't 
quite the right way to do it.  If all you do is to say that the function call 
plan doesn't explain the stop, then everybody else above you on the 
ThreadPlanStack gets a whack at the stop event.  Maybe one of them is waiting 
for a vfork stop for some other reason so they would react to this stop, which 
isn't, I think, what you wanted.  You actually want the expression to claim 
responsibility for the vfork, but also force the process to continue.

This situation is pretty much the same as for breakpoints when we're ignoring 
breakpoint hits in expressions.  The way that works is that DoPlanExplainsStop 
says it does explain the stop, but then it overrides the real stop info's 
"should stop" to force it to auto-continue.  In the breakpoint case this is in 
the `if (m_ignore_breakpoints)` branch around  line 315:

  if (m_ignore_breakpoints) {
LLDB_LOGF(log,
  "ThreadPlanCallFunction::PlanExplainsStop: we are ignoring "
  "breakpoints, overriding breakpoint stop info ShouldStop, "
  "returning true");
m_real_stop_info_sp->OverrideShouldStop(false);
return true;
  }

That way nobody else gets a look at the stop, which is I'm pretty sure what you 
want here, but when we get to deciding what to do in the ShouldStop 
negotiation, we'll continue because we forced the relevant StopInfo to do that.




Comment at: lldb/source/Target/ThreadPlanCallFunction.cpp:272
+  stop_reason == eStopReasonVForkDone) {
+LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop not done for fork 
stop reasons.");
+return false;

This is a bit silly, but "not done" sounds more to me like you didn't do 
PlanExplainsStop - which isn't true and would be weird - than that it is 
returning false.  Maybe just "returning false for fork stop reasons" would be 
better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129521

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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Mike Hommey via Phabricator via lldb-commits]

glandium added a comment.

In D112374#3651218 , @mizvekov wrote:

> Can you confirm that this `NoPrincipalGetURI` matcher would, in clang version 
> without this patch here, fail to match if you had rewritten the `GetUri` 
> method to use a qualified name?

I can confirm it's the case, and your fix works. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Matheus Izvekov via Phabricator via lldb-commits]

mizvekov added a comment.

@JDevlieghere I spent a lot of time trying to get this test running on my 
machine to no avail. I think lldb build and test setup is quite convoluted, 
fragile and antiquated. It uses many deprecated CMake features, It fails to 
properly link to system libraries it needs like librt. And I just kept patching 
these problems up and more kept coming. At some point I just gave up.

And even this test itself requires the whole libcxx it seems, which is another 
difficult thing to get building outside of CI.

I think pre-commit CI is essential here.

So I would be happy to help sort this lldb bug, but you have to help me help 
you.

I think reverting it with no prior notification was unreasonable, and landing 
this back as it was, no changes, is reasonable.

Do you agree? Please let me know soon otherwise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[Lldb-commits] [PATCH] D129814: Fix stepping over watchpoints in architectures that raise the exception before executing the instruction

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Ack, bad memory.  It was actually originally done in PerformAction, but that 
has the same effect.  You really shouldn't run the target in PerformAction if 
you can manage it.  That's why, for instance, I added a --auto-continue flag to 
the breakpoints (probably should do the same for watchpoints) so that the 
thread list code gets a chance to reason about the state before continuing.  We 
do run expressions there, but we should really only do that if (a) we know the 
expression will only run the current thread or (b) we're doing it for the user, 
where if they have an expression that requires all threads to run, they needed 
to do that and presumably were willing to trade off running the expression for 
changing the state of the other threads from what it was at the initial stop.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129814

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

[Lldb-commits] [PATCH] D129814: Fix stepping over watchpoints in architectures that raise the exception before executing the instruction

[Jim Ingham via Phabricator via lldb-commits]

jingham created this revision.
jingham added reviewers: JDevlieghere, jasonmolenda, labath, clayborg.
Herald added subscribers: atanasyan, kristof.beyls, arichardson, sdardis.
Herald added a project: All.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

On some architectures - e.g. aarch64 - the watchpoint exception is raised 
before the instruction that would have triggered it gets run.  We want to 
report old/new values, however, so we need to have executed the instruction 
before reporting the stop.  That means before reporting the stop, we need to do 
one stepi on the thread that got the watchpoint exception.

The original version of this code implemented this incorrectly.  It did the 
step over synchronously in the StopInfoWatchpoint::ShouldStopSynchronous.  You 
should NEVER run the target in ShouldStopSynchronous.  If you do that, then any 
other threads that had interesting pending stop info actions won't be able to 
perform their action because the target will have moved on and invalidated 
their StopInfo's.

You should always do this kind of thing by pushing the action you want to 
perform onto the ThreadPlanStack for the thread in question.  That way all the 
threads get to register what they need to do, and then the ThreadList runner 
can arbitrate among them and do the right thing.  For instance, in the case of 
stepping over watchpoints, each thread stopped on the watchpoint pushes a "step 
instruction" thread plan that re-instates the original watchpoint StopInfo when 
complete.  If there is more than one thread in this state, lldb notices each of 
them has a "stop others" plan, and one by one lets each thread step over the 
watchpoint.  When all this work is done, we report all the threads stopped at 
their watchpoints.

I also fixed a bug in the same code I noticed while reworking this.  We were 
not decrementing the HitCount for the watchpoint if the condition fails.  We 
consider a failed condition to mean "the stop point wasn't hit".  It's weird to 
see a hit count of 5 when the target only told you about one stop...  But that 
wasn't being enforced in the StopInfoWatchpoint::PerformAction.

There was a test that was expecting the now-incorrect value of the hit count in 
this case, so I fixed that, and also all the tests that were failing because of 
concurrent access were turned on again and run successfully for me.

There's a bit of funniness for MIPS in the watchpoint support.  I am pretty 
sure I got that right, but I don't have anything MIPS to test that on.  The 
same concurrent watchpoint tests that were marked failing for arm64 Darwin are 
also marked failed for MIPS, but I am not sure if that's for the same reason.  
Anyway, if someone has access to a MIPS system, it would be good to try this 
out and see if it works there as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129814

Files:
  lldb/include/lldb/Breakpoint/Watchpoint.h
  lldb/include/lldb/Target/StopInfo.h
  lldb/source/Target/StopInfo.cpp
  
lldb/test/API/commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentManyWatchpoints.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py

Index: lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py
===
--- lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py
+++ lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py
@@ -12,10 +12,6 @@
 # Atomic sequences are not supported yet for MIPS in LLDB.
 @skipIf(triple='^mips')
 @add_test_categories(["watchpoint"])
-@skipIf(
-oslist=["ios", "watchos", "tvos", "bridgeos", "macosx"],
-archs=['arm64', 'arm64e', 'arm64_32', 'arm'],
-bugnumber="rdar://93863107")
 
 def test(self):
 """Test watchpoint and a breakpoint in multiple threads."""
Index: 

[Lldb-commits] [PATCH] D129703: [lldb] Refactor command option enum values (NFC)

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/source/Commands/CommandObjectBreakpointCommand.cpp:25-54
-// FIXME: "script-type" needs to have its contents determined dynamically, so
-// somebody can add a new scripting language to lldb and have it pickable here
-// without having to change this enumeration by hand and rebuild lldb proper.
-static constexpr OptionEnumValueElement g_script_option_enumeration[] = {
-{
-eScriptLanguageNone,
-"command",

JDevlieghere wrote:
> clayborg wrote:
> > instead of moving all of these global enum declarations into 
> > CommandOptionArgumentTable.h, can we register the enum type in a static 
> > Initalize method? Maybe leave this code here and then add a function that 
> > would register a given enum type with the command interpreter so they can 
> > be displayed?
> > ```
> > static void CommandObjectBreakpointCommandAdd::Initialize() {
> >   
> > CommandInterpreter::RegisterEnumerationOption(g_script_option_enumeration, 
> > "");
> > }
> > ```
> > Then we can leave these definitions where they live, but register then so 
> > they can be seen in the help?
> That's a great question. 
> 
> At a technical level that wouldn't work because of the way the option 
> definitions are currently generated. All these tables and their entries are 
> built at compile time (i.e. they're all `constexpr`). I didn't dig into why 
> that's necessary, but I'm assuming there is a reason for it. But even if we 
> were to change that, these enums shouldn't belong to a specific command. 
> Multiple commands can share these argument types so in that sense it only 
> makes sense that their values are shared as well. Before this patch, it's 
> totally possible to specify that something takes an argument  and one 
> commands accepts a certain set of enum values while the other accepts a 
> totally different set. By centralizing them, there's a unique mapping between 
> argument type and its values, which is exactly what we need to display them 
> in the help. 
Makes sense


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

https://reviews.llvm.org/D129703

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

[Lldb-commits] [PATCH] D129807: [LLDB][NativePDB] Add MSInheritanceAttr when completing CXXRecordDecl

[Zequan Wu via Phabricator via lldb-commits]

zequanwu created this revision.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129807

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h


Index: lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
===
--- lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
+++ lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
@@ -57,6 +57,7 @@
   llvm::DenseMap, 8>>
   _cxx_record_map;
+  bool has_virtual_base = false;
 
 public:
   UdtRecordCompleter(
Index: lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
@@ -123,6 +123,7 @@
 
 Error UdtRecordCompleter::visitKnownMember(CVMemberRecord ,
VirtualBaseClassRecord ) {
+  has_virtual_base = true;
   AddBaseClassForTypeIndex(base.BaseType, base.getAccess(), base.VTableIndex);
 
   return Error::success();
@@ -312,6 +313,17 @@
   TypeSystemClang::CompleteTagDeclarationDefinition(m_derived_ct);
 
   if (auto *record_decl = llvm::dyn_cast(_tag_decl)) {
+clang::MSInheritanceAttr::Spelling spelling;
+if (has_virtual_base)
+  spelling = clang::MSInheritanceAttr::Keyword_virtual_inheritance;
+else if (bases.size() > 1)
+  spelling = clang::MSInheritanceAttr::Keyword_multiple_inheritance;
+else
+  spelling = clang::MSInheritanceAttr::Keyword_single_inheritance;
+clang::MSInheritanceAttr *inheritance_attr =
+clang::MSInheritanceAttr::CreateImplicit(
+m_ast_builder.clang().getASTContext(), spelling);
+record_decl->addAttr(inheritance_attr);
 m_ast_builder.importer().SetRecordLayout(record_decl, m_layout);
   }
 }


Index: lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
===
--- lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
+++ lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
@@ -57,6 +57,7 @@
   llvm::DenseMap, 8>>
   _cxx_record_map;
+  bool has_virtual_base = false;
 
 public:
   UdtRecordCompleter(
Index: lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
@@ -123,6 +123,7 @@
 
 Error UdtRecordCompleter::visitKnownMember(CVMemberRecord ,
VirtualBaseClassRecord ) {
+  has_virtual_base = true;
   AddBaseClassForTypeIndex(base.BaseType, base.getAccess(), base.VTableIndex);
 
   return Error::success();
@@ -312,6 +313,17 @@
   TypeSystemClang::CompleteTagDeclarationDefinition(m_derived_ct);
 
   if (auto *record_decl = llvm::dyn_cast(_tag_decl)) {
+clang::MSInheritanceAttr::Spelling spelling;
+if (has_virtual_base)
+  spelling = clang::MSInheritanceAttr::Keyword_virtual_inheritance;
+else if (bases.size() > 1)
+  spelling = clang::MSInheritanceAttr::Keyword_multiple_inheritance;
+else
+  spelling = clang::MSInheritanceAttr::Keyword_single_inheritance;
+clang::MSInheritanceAttr *inheritance_attr =
+clang::MSInheritanceAttr::CreateImplicit(
+m_ast_builder.clang().getASTContext(), spelling);
+record_decl->addAttr(inheritance_attr);
 m_ast_builder.importer().SetRecordLayout(record_decl, m_layout);
   }
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D129703: [lldb] Refactor command option enum values (NFC)

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere marked an inline comment as done.
JDevlieghere added inline comments.



Comment at: lldb/source/Commands/CommandObjectBreakpointCommand.cpp:25-54
-// FIXME: "script-type" needs to have its contents determined dynamically, so
-// somebody can add a new scripting language to lldb and have it pickable here
-// without having to change this enumeration by hand and rebuild lldb proper.
-static constexpr OptionEnumValueElement g_script_option_enumeration[] = {
-{
-eScriptLanguageNone,
-"command",

clayborg wrote:
> instead of moving all of these global enum declarations into 
> CommandOptionArgumentTable.h, can we register the enum type in a static 
> Initalize method? Maybe leave this code here and then add a function that 
> would register a given enum type with the command interpreter so they can be 
> displayed?
> ```
> static void CommandObjectBreakpointCommandAdd::Initialize() {
>   CommandInterpreter::RegisterEnumerationOption(g_script_option_enumeration, 
> "");
> }
> ```
> Then we can leave these definitions where they live, but register then so 
> they can be seen in the help?
That's a great question. 

At a technical level that wouldn't work because of the way the option 
definitions are currently generated. All these tables and their entries are 
built at compile time (i.e. they're all `constexpr`). I didn't dig into why 
that's necessary, but I'm assuming there is a reason for it. But even if we 
were to change that, these enums shouldn't belong to a specific command. 
Multiple commands can share these argument types so in that sense it only makes 
sense that their values are shared as well. Before this patch, it's totally 
possible to specify that something takes an argument  and one commands 
accepts a certain set of enum values while the other accepts a totally 
different set. By centralizing them, there's a unique mapping between argument 
type and its values, which is exactly what we need to display them in the help. 


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

https://reviews.llvm.org/D129703

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

[Lldb-commits] [PATCH] D93951: [vscode] Improve runInTerminal and support linux

[Arthur Eubanks via Phabricator via lldb-commits]

aeubanks added a comment.
Herald added a project: All.

Hi, sorry to ping a very old patch but `TestVSCode_runInTerminal.py` is still 
failing on my linux machine (and a coworker said the same thing). Searching my 
email for the test name, some 12.0.0 and 13.0.0 release email threads also 
mention this test failing.

Commenting out all the tests except for `test_runInTerminal` and with the 
following print:

  --- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  +++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  @@ -329,6 +329,7 @@ class VSCodeTestCaseBase(TestBase):
   return response
   
   if not (response and response['success']):
  +print(response)
   self.assertTrue(response['success'],
   'launch failed (%s)' % (response['message']))
   # We need to trigger a request_configurationDone after we've 
successfully
  $ ./bin/llvm-lit -vv 
../../lldb/test/API/tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py
  -- Testing: 1 tests, 1 workers --
  FAIL: lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py 
(1 of 1)
   TEST 'lldb-api :: 
tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py' FAILED 

  Script:
  --
  /usr/local/google/home/aeubanks/repos/sysroot/usr/bin/python3.10 
/usr/local/google/home/aeubanks/repos/llvm-project/lldb/test/API/dotest.py -u 
CXXFLAGS -u CFLAGS --env 
ARCHIVER=/usr/local/google/home/aeubanks/repos/sysroot/usr/local/google/home/aeubanks/repos/chromium/src/third_party/llvm-build/Release+Asserts/bin/llvm-ar
 --env 
OBJCOPY=/usr/local/google/home/aeubanks/repos/sysroot/usr/local/google/home/aeubanks/repos/chromium/src/third_party/llvm-build/Release+Asserts/bin/llvm-objcopy
 --env 
LLVM_LIBS_DIR=/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./lib
 --env 
LLVM_INCLUDE_DIR=/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/include
 --env 
LLVM_TOOLS_DIR=/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./bin
 --hermetic-libcxx --arch x86_64 --build-dir 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/lldb-test-build.noindex
 --lldb-module-cache-dir 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./bin/lldb 
--compiler 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./bin/clang 
--dsymutil 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./bin/dsymutil 
--llvm-tools-dir 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./bin 
--lldb-libs-dir 
/usr/local/google/home/aeubanks/repos/llvm-project/build/cmake/./lib 
/usr/local/google/home/aeubanks/repos/llvm-project/lldb/test/API/tools/lldb-vscode/runInTerminal
 -p TestVSCode_runInTerminal.py
  --
  Exit Code: 1
  
  Command Output (stdout):
  --
  lldb version 15.0.0git (g...@github.com:aeubanks/llvm-project.git revision 
2f11b3a6d7b8083be570f79f4ca18dfb2648eda3)
clang revision 2f11b3a6d7b8083be570f79f4ca18dfb2648eda3
llvm revision 2f11b3a6d7b8083be570f79f4ca18dfb2648eda3
  Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 
'debugserver', 'objc']
  {'command': 'launch', 'message': 'Failed to attach to the target process. 
Timed out trying to get messages from the runInTerminal launcher', 
'request_seq': 2, 'seq': 0, 'success': False, 'type': 'response'}
  = DEBUG ADAPTER PROTOCOL LOGS =
  --> 
  Content-Length: 284
  
  
{"command":"initialize","type":"request","arguments":{"adapterID":"lldb-native","clientID":"vscode","columnsStartAt1":true,"linesStartAt1":true,"locale":"en-us","pathFormat":"path","supportsRunInTerminalRequest":true,"supportsVariablePaging":true,"supportsVariableType":true},"seq":1}
  <-- 
  Content-Length: 1246
  
  
{"body":{"exceptionBreakpointFilters":[{"default":false,"filter":"cpp_catch","label":"C++
 Catch"},{"default":false,"filter":"cpp_throw","label":"C++ 
Throw"},{"default":false,"filter":"objc_catch","label":"Objective-C 
Catch"},{"default":false,"filter":"objc_throw","label":"Objective-C 
Throw"},{"default":false,"filter":"swift_catch","label":"Swift 
Catch"},{"default":false,"filter":"swift_throw","label":"Swift 

[Lldb-commits] [PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D128465#3653216 , @ckissane wrote:

> In D128465#3653051 , @jasonmolenda 
> wrote:
>
>> In D128465#3652525 , @ckissane 
>> wrote:
>>
>>> In D128465#3651025 , @aemerson 
>>> wrote:
>>>
 I just reverted this in 6e6be5f9504d 
  
 because it seems to have broken macOS builds:

   llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not 
 found
   #include 
^~~~
>>>
>>> @aemerson Could you provide the output of your cmake command?
>>> (I can't easily reproduce because I don't have a mac on hand)
>>
>> FWIW I hit this last night on my mac desktop - it looked like I had zstd 
>> installed by homebrew (as a dependency on something I installed), and cmake 
>> was able to find it in /opt/homebrew (somehow) but when Compression.cpp was 
>> built, nothing had added -I/opt/homebrew/include so the header wasn't found. 
>>  I hacked the FindZSTD.cmake to not find it, to finish what I was working on 
>> before bedtime.  This might not be related to what @aemerson saw though.
>
> @jasonmolenda Thank you for the info, I believe it is similar, could you try: 
> https://reviews.llvm.org/D129786 for me?

I applied the patch from https://reviews.llvm.org/D129786 on a clean checkout, 
` cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=1 
-DLLVM_ENABLE_PROJECTS='llvm;lldb;clang' 
'-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi' -DLLDB_ENABLE_PYTHON=1` (my normal 
cmake line) and got

  -- Found ZSTD: /opt/homebrew/lib/libzstd.dylib  
  -- Looking for ZSTD_compress
  -- Looking for ZSTD_compress - found
  
  [...]
  
  FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o 
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
 -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/Users/jason/k/llvm/llvm-project/build/lib/Support 
-I/Users/jason/k/llvm/llvm-project/llvm/lib/Support 
-I/Users/jason/k/llvm/llvm-project/build/include 
-I/Users/jason/k/llvm/llvm-project/llvm/include -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -fdiagnostics-color  -g -arch arm64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
 -std=c++14  -fno-exceptions -fno-rtti -MD -MT 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o -MF 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o.d -o 
lib/Support/CMakeFiles/LLVMSupport.dir/Compression.cpp.o -c 
/Users/jason/k/llvm/llvm-project/llvm/lib/Support/Compression.cpp
  /Users/jason/k/llvm/llvm-project/llvm/lib/Support/Compression.cpp:24:10: 
fatal error: 'zstd.h' file not found
  #include 
   ^~~~
  1 error generated.
  
  % file /opt/homebrew/lib/libzstd.dylib 
  /opt/homebrew/lib/libzstd.dylib: Mach-O 64-bit dynamically linked shared 
library arm64
  % head -2 /opt/homebrew/include/zstd.h 
  /*
   * Copyright (c) Yann Collet, Facebook, Inc.
  %
  
  % grep -i zstd CMakeCache.txt 
  //Use zstd for compression/decompression if available. Can be ON,
  LLVM_ENABLE_ZSTD:STRING=ON
  ZSTD_INCLUDE_DIR:PATH=/opt/homebrew/include
  ZSTD_LIBRARY:FILEPATH=/opt/homebrew/lib/libzstd.dylib
  //Details about finding ZSTD
  
FIND_PACKAGE_MESSAGE_DETAILS_ZSTD:INTERNAL=[/opt/homebrew/lib/libzstd.dylib][/opt/homebrew/include][v()]
  //Have symbol ZSTD_compress
  HAVE_ZSTD:INTERNAL=1
  //ADVANCED property for variable: ZSTD_INCLUDE_DIR
  ZSTD_INCLUDE_DIR-ADVANCED:INTERNAL=1
  //ADVANCED property for variable: ZSTD_LIBRARY
  ZSTD_LIBRARY-ADVANCED:INTERNAL=1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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

[Lldb-commits] [PATCH] D129703: [lldb] Refactor command option enum values (NFC)

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: lldb/source/Commands/CommandObjectBreakpointCommand.cpp:25-54
-// FIXME: "script-type" needs to have its contents determined dynamically, so
-// somebody can add a new scripting language to lldb and have it pickable here
-// without having to change this enumeration by hand and rebuild lldb proper.
-static constexpr OptionEnumValueElement g_script_option_enumeration[] = {
-{
-eScriptLanguageNone,
-"command",

instead of moving all of these global enum declarations into 
CommandOptionArgumentTable.h, can we register the enum type in a static 
Initalize method? Maybe leave this code here and then add a function that would 
register a given enum type with the command interpreter so they can be 
displayed?
```
static void CommandObjectBreakpointCommandAdd::Initialize() {
  CommandInterpreter::RegisterEnumerationOption(g_script_option_enumeration, 
"");
}
```
Then we can leave these definitions where they live, but register then so they 
can be seen in the help?


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

https://reviews.llvm.org/D129703

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

[Lldb-commits] [PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Cole Kissane via Phabricator via lldb-commits]

ckissane added a comment.

In D128465#3653051 , @jasonmolenda 
wrote:

> In D128465#3652525 , @ckissane 
> wrote:
>
>> In D128465#3651025 , @aemerson 
>> wrote:
>>
>>> I just reverted this in 6e6be5f9504d 
>>>  
>>> because it seems to have broken macOS builds:
>>>
>>>   llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not 
>>> found
>>>   #include 
>>>^~~~
>>
>> @aemerson Could you provide the output of your cmake command?
>> (I can't easily reproduce because I don't have a mac on hand)
>
> FWIW I hit this last night on my mac desktop - it looked like I had zstd 
> installed by homebrew (as a dependency on something I installed), and cmake 
> was able to find it in /opt/homebrew (somehow) but when Compression.cpp was 
> built, nothing had added -I/opt/homebrew/include so the header wasn't found.  
> I hacked the FindZSTD.cmake to not find it, to finish what I was working on 
> before bedtime.  This might not be related to what @aemerson saw though.

@jasonmolenda Thank you for the info, I believe it is similar, could you try: 
https://reviews.llvm.org/D129786 for me?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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

[Lldb-commits] [PATCH] D129783: [lldb] Skip tests using int128 on ARM

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

A very minor point but API tests don't need `mydir = 
TestBase.compute_mydir(__file__)` any more thanks to 
https://reviews.llvm.org/D128077 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129783

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

[Lldb-commits] [PATCH] D129682: [lldb] Filter DIEs based on qualified name when possible

[Alex Langford via Phabricator via lldb-commits]

bulbazord added a comment.

In D129682#3651175 , @labath wrote:

> Well.. first of let me say that the performance gain is impressive. I 
> wouldn't have expected to gain that much with a relatively simple change.

Thank you! I am also very surprised, it turned out to be a worthwhile time 
investment.

> - Do we really need the `GetQualifiedNameWithParams` function? My impression 
> was that we've been moving towards ignoring function arguments for name 
> matching, and `CPlusPlusLanguage::DemangledNameContainsPath` does not look 
> like it is making use of that. Note that I don't think that switching to 
> `GetQualifiedName` is the right approach either. I think we should use the 
> mangled name (`GetMangledName`) first, and only fall back to 
> `GetQualifiedName` if that is unavailable (you can look up how it works 
> during SymbolContext construction, but I believe it is roughly like that. 
> (Incidentally, that will bring in the function arguments through the back 
> door for some/most functions, but that isn't my motivation.)

My reasoning for writing `GetQualifiedNameWithParams` instead of just using 
`GetQualifiedName` is because of matching overloaded names. It's valid for a 
user to set a breakpoint like `b a_function(int)` to disambiguate any other 
functions named `a_function`. Without the parameter list, we would be setting a 
breakpoint on every `a_function` which is not correct if you specify the 
argument list. I originally used `GetQualifiedName` but TestBreakOnOverload 
failed...
That being said, I'm not sure how we would use a mangled name to perform the 
match. We're specifically matching on user input for breakpoints, so if a user 
inputs something like `StringView::begin`, how would we match that against 
mangled names? We would need some way to partially mangle `StringView::begin` 
and match that against the mangled name from the DIE, right? It would probably 
be faster to match against a mangled name though, so if there is a way to make 
that work that would be perfect.

> - This patch is duplicating some of the logic inside 
> `Module::LookupInfo::Prune`. I get that we can't reuse it as-is (because we'd 
> need a `SymbolContext` object), but it seems like that function only cares 
> about the `GetFunctionName` portion of the object, so it seems like it should 
> be possible to refactor it such that one can reuse it from within this new 
> context (just pass in a name instead of a full SymbolContext). (I guess this 
> part could be a separate patch)

Specifically you're suggesting a refactor of `Module::LookupInfo::Prune` so 
that we can deduplicate the logic right? I'd actually like to see if we can get 
rid of `Module::LookupInfo::Prune` altogether so we don't have to post-process 
search results but instead filter them as we find them. I hope I've 
accomplished at least some of that with this change, but getting rid of it 
entirely would require a few more changes in `Symtab` and in the other 
SymbolFile implementations (I think...).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129682

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

[Lldb-commits] [PATCH] D129377: [lldb/Fuzzer] Add fuzzer for expression evaluator

[Chelsea Cassanova via Phabricator via lldb-commits]

cassanova updated this revision to Diff 444761.
cassanova edited the summary of this revision.
cassanova added a comment.

Removed the cxx_proto.proto file since we include the headers that it generates 
from the clang side.


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

https://reviews.llvm.org/D129377

Files:
  clang/cmake/modules/ProtobufMutator.cmake
  clang/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
  clang/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt
  lldb/tools/lldb-fuzzer/CMakeLists.txt
  lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/CMakeLists.txt
  lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/lldb-expression-fuzzer.cpp

Index: lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/lldb-expression-fuzzer.cpp
===
--- /dev/null
+++ lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/lldb-expression-fuzzer.cpp
@@ -0,0 +1,73 @@
+//===-- lldb-expression-fuzzer.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===-===//
+//
+// \file
+// This file is a fuzzer for LLDB's expression evaluator. It uses protobufs
+// and the libprotobuf-mutator to create valid C-like inputs for the
+// expression evaluator.
+//
+//===-===//
+
+#include 
+
+#include "cxx_proto.pb.h"
+#include "handle_cxx.h"
+#include "lldb/API/SBBreakpoint.h"
+#include "lldb/API/SBDebugger.h"
+#include "lldb/API/SBError.h"
+#include "lldb/API/SBLaunchInfo.h"
+#include "lldb/API/SBProcess.h"
+#include "lldb/API/SBTarget.h"
+#include "proto_to_cxx.h"
+#include "src/libfuzzer/libfuzzer_macro.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
+
+using namespace lldb;
+using namespace llvm;
+using namespace clang_fuzzer;
+
+char **originalargv;
+
+extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) {
+  SBDebugger::Initialize();
+
+  // The path for a simple compiled program is needed to create a
+  // target for the debugger and that path is passed in through argv
+  originalargv = *argv;
+  return 0;
+}
+
+DEFINE_BINARY_PROTO_FUZZER(const clang_fuzzer::Function ) {
+  auto S = clang_fuzzer::FunctionToString(input);
+
+  // Get the second argument from argv and strip the '--' from it.
+  // This will be used as the path for the object file to create a target from
+  std::string rawpath = originalargv[2];
+  StringRef objpath = rawpath.erase(0, 2);
+
+  // Create a debugger and a target
+  SBDebugger debugger = SBDebugger::Create(false);
+  SBTarget target = debugger.CreateTarget(objpath.str().c_str());
+
+  // Create a breakpoint on the only line in the program
+  SBBreakpoint bp = target.BreakpointCreateByLocation(objpath.str().c_str(), 1);
+
+  // Create launch info and error for launching the process
+  SBLaunchInfo li = target.GetLaunchInfo();
+  SBError error;
+
+  // Launch the process and evaluate the fuzzer's input data
+  // as an expression
+  SBProcess process = target.Launch(li, error);
+  target.EvaluateExpression(S.c_str());
+
+  debugger.DeleteTarget(target);
+  SBDebugger::Destroy(debugger);
+  SBModule::GarbageCollectAllocatedModules();
+}
Index: lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/CMakeLists.txt
===
--- /dev/null
+++ lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/CMakeLists.txt
@@ -0,0 +1,57 @@
+if(CLANG_ENABLE_PROTO_FUZZER)
+  set(LLVM_LINK_COMPONENTS
+Support
+)
+
+  add_llvm_fuzzer(lldb-expression-fuzzer
+EXCLUDE_FROM_ALL
+lldb-expression-fuzzer.cpp
+)
+
+  if(TARGET lldb-expression-fuzzer)
+target_include_directories(lldb-expression-fuzzer PRIVATE ..)
+find_package(Protobuf REQUIRED)
+add_definitions(-DGOOGLE_PROTOBUF_NO_RTTI)
+include_directories(${PROTOBUF_INCLUDE_DIRS})
+include_directories(${CMAKE_CURRENT_BINARY_DIR}/../../../../clang/tools/clang-fuzzer PRIVATE ..)
+
+set(CLANG_CMAKE_MODULE_PATH
+  ${CMAKE_CURRENT_SOURCE_DIR}/../../../../clang/cmake/modules)
+
+set(CMAKE_MODULE_PATH
+  ${CMAKE_MODULE_PATH}
+  ${CLANG_CMAKE_MODULE_PATH})
+
+
+set (PBM_PREFIX lldb_protobuf_mutator)
+include(ProtobufMutator)
+include_directories(${ProtobufMutator_INCLUDE_DIRS})
+
+target_link_libraries(lldb-expression-fuzzer
+  PRIVATE
+  ${ProtobufMutator_LIBRARIES}
+  ${LLVM_LIB_FUZZING_ENGINE}
+  clangHandleCXX
+  clangCXXProto
+  clangProtoToCXX
+  liblldb
+  )
+
+add_custom_command(TARGET lldb-expression-fuzzer PRE_BUILD
+  COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_BINARY_DIR}/fuzzer-artifacts/expression-artifacts
+  # Create and compile a simple C program using the command line. This is
+  

[Lldb-commits] [PATCH] D129377: [lldb/Fuzzer] Add fuzzer for expression evaluator

[Chelsea Cassanova via Phabricator via lldb-commits]

cassanova marked an inline comment as done.
cassanova added inline comments.



Comment at: lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/cxx_proto.proto:1
+//===-- cxx_proto.proto - Protobuf description of C++ 
-===//
+//

JDevlieghere wrote:
> Do we still need a copy of this for LLDB?
This file is used to generate the cxx_proto.pb.h which is included in the 
source file. Since we just use the clang-fuzzer directory as an include 
directory then we shouldn't need this file anymore 


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

https://reviews.llvm.org/D129377

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

[Lldb-commits] [PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Cole Kissane via Phabricator via lldb-commits]

ckissane added a comment.

@aemerson can you let me know if https://reviews.llvm.org/D129786 works on 
MacOS?
I am continuing work on that revision because this one has a lot of outdated 
unrelated history.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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

[Lldb-commits] [PATCH] D128893: [lldb] [llgs] Fix disabling non-stop mode

[Michał Górny via Phabricator via lldb-commits]

mgorny updated this revision to Diff 444727.
mgorny added a comment.

Use a single `bool` member to indicate whether we're still waiting for any 
process to stop. Turned out pretty easy.


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

https://reviews.llvm.org/D128893

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/test/API/tools/lldb-server/TestNonStop.py

Index: lldb/test/API/tools/lldb-server/TestNonStop.py
===
--- lldb/test/API/tools/lldb-server/TestNonStop.py
+++ lldb/test/API/tools/lldb-server/TestNonStop.py
@@ -366,3 +366,33 @@
  "send packet: $OK#00",
  ], True)
 self.expect_gdbremote_sequence()
+
+@add_test_categories(["llgs"])
+def test_leave_nonstop(self):
+self.build()
+self.set_inferior_startup_launch()
+procs = self.prep_debug_monitor_and_inferior(
+inferior_args=["thread:new", "thread:new", "stop", "sleep:15"])
+self.test_sequence.add_log_lines(
+["read packet: $QNonStop:1#00",
+ "send packet: $OK#00",
+ # stop is used to synchronize starting threads
+ "read packet: $c#63",
+ "send packet: $OK#00",
+ {"direction": "send", "regex": "%Stop:T.*"},
+ "read packet: $c#63",
+ "send packet: $OK#00",
+ # verify that the threads are running now
+ "read packet: $?#00",
+ "send packet: $OK#00",
+ "read packet: $QNonStop:0#00",
+ "send packet: $OK#00",
+ # we should issue some random request now to verify that the stub
+ # did not send stop reasons -- we may verify whether notification
+ # queue was cleared while at it
+ "read packet: $vStopped#00",
+ "send packet: $Eff#00",
+ "read packet: $?#00",
+ {"direction": "send", "regex": "[$]T.*"},
+ ], True)
+self.expect_gdbremote_sequence()
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -117,6 +117,7 @@
   bool m_thread_suffix_supported = false;
   bool m_list_threads_in_stop_reply = false;
   bool m_non_stop = false;
+  bool m_disabling_non_stop = false;
   std::deque m_stdio_notification_queue;
   std::deque m_stop_notification_queue;
 
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1919,6 +1919,20 @@
 bool force_synchronous) {
   Log *log = GetLog(LLDBLog::Process);
 
+  if (m_disabling_non_stop) {
+// Check if we are waiting for any more processes to stop.  If we are,
+// do not send the OK response yet.
+for (const auto  : m_debugged_processes) {
+  if (it.second.process_up->IsRunning())
+return PacketResult::Success;
+}
+
+// If all expected processes were stopped after a QNonStop:0 request,
+// send the OK response.
+m_disabling_non_stop = false;
+return SendOKResponse();
+  }
+
   switch (process_state) {
   case eStateAttaching:
   case eStateLaunching:
@@ -3903,12 +3917,33 @@
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerLLGS::Handle_QNonStop(
 StringExtractorGDBRemote ) {
+  Log *log = GetLog(LLDBLog::Process);
+
   StringRef packet_str{packet.GetStringRef()};
   assert(packet_str.startswith("QNonStop:"));
   packet_str.consume_front("QNonStop:");
   if (packet_str == "0") {
+for (auto _it : m_debugged_processes) {
+  if (process_it.second.process_up->IsRunning()) {
+assert(m_non_stop);
+Status error = process_it.second.process_up->Interrupt();
+if (error.Fail()) {
+  LLDB_LOG(log,
+   "while disabling nonstop, failed to halt process {0}: {1}",
+   process_it.first, error);
+  return SendErrorResponse(0x41);
+}
+// we must not send stop reasons after QNonStop
+m_disabling_non_stop = true;
+  }
+}
+m_stdio_notification_queue.clear();
+m_stop_notification_queue.clear();
 m_non_stop = false;
-// TODO: stop all threads
+// If we are stopping anything, defer sending the OK response until we're
+// done.
+if (m_disabling_non_stop)
+  return PacketResult::Success;
   } else if (packet_str == "1") {
 m_non_stop = true;
   } else
___

[Lldb-commits] [lldb] c3a28e8 - Revert "[lldb] Add support for using integral const static data members in the expression evaluator"

[Stella Stamenova via lldb-commits]

Author: Stella Stamenova
Date: 2022-07-14T10:47:01-07:00
New Revision: c3a28e8a99a6672339a38c468f2519ace5659fa2

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

LOG: Revert "[lldb] Add support for using integral const static data members in 
the expression evaluator"

This reverts commit 486787210df5ce5eabadc90a7de353ae81101feb.

This broke the windows lldb bot: 
https://lab.llvm.org/buildbot/#/builders/83/builds/21186

Added: 


Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp

Removed: 
lldb/test/API/lang/cpp/const_static_integral_member/Makefile

lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
lldb/test/API/lang/cpp/const_static_integral_member_int128/Makefile

lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
lldb/test/API/lang/cpp/const_static_integral_member_int128/main.cpp



diff  --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
index 799ae29e2841c..7a1ac78705474 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
@@ -197,27 +197,6 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
   return ret;
 }
 
-/// Returns true if LLDB can take the address of the given lvalue for the sake
-/// of capturing the expression result. Returns false if LLDB should instead
-/// store the expression result in a result variable.
-static bool CanTakeAddressOfLValue(const Expr *lvalue_expr) {
-  assert(lvalue_expr->getValueKind() == VK_LValue &&
- "lvalue_expr not a lvalue");
-
-  QualType qt = lvalue_expr->getType();
-  // If the lvalue has const-qualified non-volatile integral or enum type, then
-  // the underlying value might come from a const static data member as
-  // described in C++11 [class.static.data]p3. If that's the case, then the
-  // value might not have an address if the user didn't also define the member
-  // in a namespace scope. Taking the address would cause that LLDB later fails
-  // to link the expression, so those lvalues should be stored in a result
-  // variable.
-  if (qt->isIntegralOrEnumerationType() && qt.isConstQualified() &&
-  !qt.isVolatileQualified())
-return false;
-  return true;
-}
-
 bool ASTResultSynthesizer::SynthesizeBodyResult(CompoundStmt *Body,
 DeclContext *DC) {
   Log *log = GetLog(LLDBLog::Expressions);
@@ -286,10 +265,6 @@ bool 
ASTResultSynthesizer::SynthesizeBodyResult(CompoundStmt *Body,
   //   - During dematerialization, $0 is marked up as a load address with value
   // equal to the contents of the structure entry.
   //
-  //   - Note: if we cannot take an address of the resulting Lvalue (e.g. it's
-  // a static const member without an out-of-class definition), then we
-  // follow the Rvalue route.
-  //
   // For Rvalues
   //
   //   - In AST result synthesis the expression E is transformed into an
@@ -329,7 +304,7 @@ bool 
ASTResultSynthesizer::SynthesizeBodyResult(CompoundStmt *Body,
 
   clang::VarDecl *result_decl = nullptr;
 
-  if (is_lvalue && CanTakeAddressOfLValue(last_expr)) {
+  if (is_lvalue) {
 IdentifierInfo *result_ptr_id;
 
 if (expr_type->isFunctionType())

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 10dc8d1fb7c39..4b9354371bda3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2390,7 +2390,6 @@ struct MemberAttributes {
   uint64_t data_bit_offset = UINT64_MAX;
   AccessType accessibility = eAccessNone;
   llvm::Optional byte_size;
-  llvm::Optional const_value_form;
   DWARFFormValue encoding_form;
   /// Indicates the byte offset of the word from the base address of the
   /// structure.
@@ -2437,9 +2436,6 @@ MemberAttributes::MemberAttributes(const DWARFDIE ,
   case DW_AT_byte_size:
 byte_size = form_value.Unsigned();
 break;
-  case DW_AT_const_value:
-const_value_form = form_value;
-break;
   case DW_AT_data_bit_offset:
 data_bit_offset = form_value.Unsigned();
 break;
@@ -2591,65 +2587,12 @@ void 

[Lldb-commits] [PATCH] D128878: [lldb] [llgs] Remove not-really-used m_inferior_prev_state

[Michał Górny via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG06b3f27fedd5: [lldb] [llgs] Remove not-really-used 
m_inferior_prev_state (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128878

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -110,7 +110,6 @@
   Communication m_stdio_communication;
   MainLoop::ReadHandleUP m_stdio_handle_up;
 
-  lldb::StateType m_inferior_prev_state = lldb::StateType::eStateInvalid;
   llvm::StringMap> m_xfer_buffer_map;
   std::mutex m_saved_registers_mutex;
   std::unordered_map m_saved_registers_map;
Index: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1077,23 +1077,13 @@
   Log *log = GetLog(LLDBLog::Process);
   LLDB_LOGF(log, "GDBRemoteCommunicationServerLLGS::%s called", __FUNCTION__);
 
-  // Send the stop reason unless this is the stop after the launch or attach.
-  switch (m_inferior_prev_state) {
-  case eStateLaunching:
-  case eStateAttaching:
-// Don't send anything per debugserver behavior.
-break;
-  default:
-// In all other cases, send the stop reason.
-PacketResult result = SendStopReasonForState(
-*process, StateType::eStateStopped, /*force_synchronous=*/false);
-if (result != PacketResult::Success) {
-  LLDB_LOGF(log,
-"GDBRemoteCommunicationServerLLGS::%s failed to send stop "
-"notification for PID %" PRIu64 ", state: eStateExited",
-__FUNCTION__, process->GetID());
-}
-break;
+  PacketResult result = SendStopReasonForState(
+  *process, StateType::eStateStopped, /*force_synchronous=*/false);
+  if (result != PacketResult::Success) {
+LLDB_LOGF(log,
+  "GDBRemoteCommunicationServerLLGS::%s failed to send stop "
+  "notification for PID %" PRIu64 ", state: eStateExited",
+  __FUNCTION__, process->GetID());
   }
 }
 
@@ -1138,9 +1128,6 @@
 }
 break;
   }
-
-  // Remember the previous state reported to us.
-  m_inferior_prev_state = state;
 }
 
 void GDBRemoteCommunicationServerLLGS::DidExec(NativeProcessProtocol *process) 
{


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -110,7 +110,6 @@
   Communication m_stdio_communication;
   MainLoop::ReadHandleUP m_stdio_handle_up;
 
-  lldb::StateType m_inferior_prev_state = lldb::StateType::eStateInvalid;
   llvm::StringMap> m_xfer_buffer_map;
   std::mutex m_saved_registers_mutex;
   std::unordered_map m_saved_registers_map;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1077,23 +1077,13 @@
   Log *log = GetLog(LLDBLog::Process);
   LLDB_LOGF(log, "GDBRemoteCommunicationServerLLGS::%s called", __FUNCTION__);
 
-  // Send the stop reason unless this is the stop after the launch or attach.
-  switch (m_inferior_prev_state) {
-  case eStateLaunching:
-  case eStateAttaching:
-// Don't send anything per debugserver behavior.
-break;
-  default:
-// In all other cases, send the stop reason.
-PacketResult result = SendStopReasonForState(
-*process, StateType::eStateStopped, /*force_synchronous=*/false);
-if (result != PacketResult::Success) {
-  LLDB_LOGF(log,
-"GDBRemoteCommunicationServerLLGS::%s failed to send stop "
-"notification for PID %" PRIu64 ", state: eStateExited",
-__FUNCTION__, process->GetID());
-}
-break;
+  PacketResult result = SendStopReasonForState(
+  *process, StateType::eStateStopped, /*force_synchronous=*/false);
+  if (result != PacketResult::Success) {
+LLDB_LOGF(log,
+  "GDBRemoteCommunicationServerLLGS::%s failed to send stop "
+  "notification for PID %" PRIu64 ", state: 

[Lldb-commits] [lldb] 06b3f27 - [lldb] [llgs] Remove not-really-used m_inferior_prev_state

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2022-07-14T19:25:54+02:00
New Revision: 06b3f27fedd5a26ad571c093ccf47d0c11b1e913

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

LOG: [lldb] [llgs] Remove not-really-used m_inferior_prev_state

Remove m_inferior_prev_state that's not suitable for multiprocess
debugging and that does not seem to be really used at all.

The only use of the variable right now is to "prevent" sending the stop
reason after attach/launch.  However, this code is never actually run
since none of the process plugins actually use eStateLaunching or
eStateAttaching.  Through adding an assert, I've confirmed that it's
never hit in any of the LLDB tests or while attaching/launching debugged
process via lldb-server and via lldb CLI.

Differential Revision: https://reviews.llvm.org/D128878
Sponsored by: The FreeBSD Foundation

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 7ddb4c80e16d..a2ea53b0e8e1 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1077,23 +1077,13 @@ void 
GDBRemoteCommunicationServerLLGS::HandleInferiorState_Stopped(
   Log *log = GetLog(LLDBLog::Process);
   LLDB_LOGF(log, "GDBRemoteCommunicationServerLLGS::%s called", __FUNCTION__);
 
-  // Send the stop reason unless this is the stop after the launch or attach.
-  switch (m_inferior_prev_state) {
-  case eStateLaunching:
-  case eStateAttaching:
-// Don't send anything per debugserver behavior.
-break;
-  default:
-// In all other cases, send the stop reason.
-PacketResult result = SendStopReasonForState(
-*process, StateType::eStateStopped, /*force_synchronous=*/false);
-if (result != PacketResult::Success) {
-  LLDB_LOGF(log,
-"GDBRemoteCommunicationServerLLGS::%s failed to send stop "
-"notification for PID %" PRIu64 ", state: eStateExited",
-__FUNCTION__, process->GetID());
-}
-break;
+  PacketResult result = SendStopReasonForState(
+  *process, StateType::eStateStopped, /*force_synchronous=*/false);
+  if (result != PacketResult::Success) {
+LLDB_LOGF(log,
+  "GDBRemoteCommunicationServerLLGS::%s failed to send stop "
+  "notification for PID %" PRIu64 ", state: eStateExited",
+  __FUNCTION__, process->GetID());
   }
 }
 
@@ -1138,9 +1128,6 @@ void 
GDBRemoteCommunicationServerLLGS::ProcessStateChanged(
 }
 break;
   }
-
-  // Remember the previous state reported to us.
-  m_inferior_prev_state = state;
 }
 
 void GDBRemoteCommunicationServerLLGS::DidExec(NativeProcessProtocol *process) 
{

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
index cdbda0e9ca8a..ebd656687da9 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -110,7 +110,6 @@ class GDBRemoteCommunicationServerLLGS
   Communication m_stdio_communication;
   MainLoop::ReadHandleUP m_stdio_handle_up;
 
-  lldb::StateType m_inferior_prev_state = lldb::StateType::eStateInvalid;
   llvm::StringMap> m_xfer_buffer_map;
   std::mutex m_saved_registers_mutex;
   std::unordered_map m_saved_registers_map;



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

[Lldb-commits] [PATCH] D129707: [lldb] Print the enum values and their description in the argument value help output

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.

nice!


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

https://reviews.llvm.org/D129707

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

[Lldb-commits] [PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Cole Kissane via Phabricator via lldb-commits]

ckissane added a comment.

In D128465#3651025 , @aemerson wrote:

> I just reverted this in 6e6be5f9504d 
>  because 
> it seems to have broken macOS builds:
>
>   llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not found
>   #include 
>^~~~

@aemerson Could you provide the output of your cmake command?
(I can't easily reproduce because I don't have a mac on hand)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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

[Lldb-commits] [PATCH] D129724: [lldb] Remove ELF .zdebug support

[Fangrui Song via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
MaskRay marked an inline comment as done.
Closed by commit rGecfaf4801cd0: [lldb] Remove ELF .zdebug support (authored by 
MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D129724?vs=444504=444707#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129724

Files:
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
  lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml

Index: lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml
===
--- lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-## NB: This is a yaml file because llvm gnu-style writing support in 14.0
-## (2022, D117744). In due time we may want to remove it from lldb as well.
-
-## Debug info generated from the following sources using clang-13
-## struct A {
-##  long a = 42;
-## };
-## extern constexpr short s = 47;
-## extern constexpr A a{};
-
-# REQUIRES: zlib
-
-# RUN: yaml2obj %s > %t
-# RUN: %lldb %t -o "target var s a" -b | FileCheck %s
-
-# CHECK: (const short) s = 47
-# CHECK: (const A) a = (a = 42)
-
 !ELF
-FileHeader:
-  Class:   ELFCLASS64
-  Data:ELFDATA2LSB
-  Type:ET_EXEC
-  Machine: EM_X86_64
-  Entry:   0x401000
-Sections:
-  - Name:.rodata
-Type:SHT_PROGBITS
-Flags:   [ SHF_ALLOC ]
-Address: 0x401000
-AddressAlign:0x8
-Offset:  0x1000
-Content: 2F002A00
-  - Name:.zdebug_info
-Type:SHT_PROGBITS
-AddressAlign:0x1
-Content: 5A4C49420077789C2B666060606100010E4610A9C820CA00012640CCE407248C81989197939941C0012CC16C01D2130024589998C280540848011F2733074C4124488E35116C28171B48493E480937505B04488A830100368605A7
-  - Name:.debug_abbrev
-Type:SHT_PROGBITS
-AddressAlign:0x1
-Content: 011101250E1305030E10171B0E023400030E49133F193A0B3B0B02180326004913042400030E3E0B0B0B051301360B030E0B0B3A0B3B0B060D00030E49133A0B3B0B380B00
-  - Name:.debug_line
-Type:SHT_PROGBITS
-AddressAlign:0x1
-Content: 3C0004003600010101FB0E0D00010101010001012F746D70676E752D7374796C652D636F6D7072657373696F6E2E63707100
-DWARF:
-  debug_str:
-- clang version 13.0.0
-- '/tmp/gnu-style-compression.cpp'
-- '/tmp/my_working_directory'
-- s
-- short
-- a
-- long int
-- A
-...
Index: lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
===
--- lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
+++ lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
@@ -16,6 +16,7 @@
 Type:SHT_PROGBITS
 Flags:   [ SHF_COMPRESSED ]
 Content: deadbeefbaadf00d
+## The legacy .zdebug format is not supported.
   - Name:.zdebug_info
 Type:SHT_PROGBITS
 Content: 5A4C49420008789c533070084828689809c802c1
@@ -37,8 +38,8 @@
 # CHECK-NEXT: Data: ()
 
 # CHECK: Name: .zdebug_info
-# CHECK: dwarf-info
+# CHECK: regular
 # CHECK: File size: 28
 # CHECK: Data: (
-# CHECK-NEXT: 20304050 60708090
+# CHECK-NEXT: 5A4C4942  0008 789C5330 70084828 6898 09C802C1
 # CHECK-NEXT: )
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1607,7 +1607,7 @@
 }
 
 static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
-  if (Name.consume_front(".debug_") || Name.consume_front(".zdebug_")) {
+  if (Name.consume_front(".debug_")) {
 return llvm::StringSwitch(Name)
 .Case("abbrev", eSectionTypeDWARFDebugAbbrev)
 .Case("abbrev.dwo", eSectionTypeDWARFDebugAbbrevDwo)
@@ -3365,8 +3365,7 @@
 return section->GetObjectFile()->ReadSectionData(section, section_data);
 
   size_t result = ObjectFile::ReadSectionData(section, section_data);
-  if (result == 0 || !llvm::object::Decompressor::isCompressedELFSection(
- section->Get(), section->GetName().GetStringRef()))
+  if (result == 0 || !(section->Get() & llvm::ELF::SHF_COMPRESSED))
 return result;
 
   auto Decompressor = llvm::object::Decompressor::create(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D129724: [lldb] Remove ELF .zdebug support

[Fangrui Song via Phabricator via lldb-commits]

MaskRay marked an inline comment as done.
MaskRay added inline comments.



Comment at: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1610
 static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
   if (Name.consume_front(".debug_") || Name.consume_front(".zdebug_")) {
 return llvm::StringSwitch(Name)

labath wrote:
> I guess you can remove this as well now.
Thanks. Will delete when committing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129724

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

[Lldb-commits] [lldb] ecfaf48 - [lldb] Remove ELF .zdebug support

[Fangrui Song via lldb-commits]

Author: Fangrui Song
Date: 2022-07-14T10:12:48-07:00
New Revision: ecfaf4801cd0cc85fdced820110652f0281765fa

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

LOG: [lldb] Remove ELF .zdebug support

clang 14 removed -gz=zlib-gnu support and ld.lld/llvm-objcopy removed zlib-gnu
support recently. Remove lldb support by migrating away from
llvm::object::Decompressor::isCompressedELFSection.
The API has another user llvm-dwp, so it is not removed in this patch.

Reviewed By: labath

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

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml

Removed: 
lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml



diff  --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index f9fb36890d5ac..122298d87bf8d 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1607,7 +1607,7 @@ lldb::user_id_t 
ObjectFileELF::GetSectionIndexByName(const char *name) {
 }
 
 static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
-  if (Name.consume_front(".debug_") || Name.consume_front(".zdebug_")) {
+  if (Name.consume_front(".debug_")) {
 return llvm::StringSwitch(Name)
 .Case("abbrev", eSectionTypeDWARFDebugAbbrev)
 .Case("abbrev.dwo", eSectionTypeDWARFDebugAbbrevDwo)
@@ -3365,8 +3365,7 @@ size_t ObjectFileELF::ReadSectionData(Section *section,
 return section->GetObjectFile()->ReadSectionData(section, section_data);
 
   size_t result = ObjectFile::ReadSectionData(section, section_data);
-  if (result == 0 || !llvm::object::Decompressor::isCompressedELFSection(
- section->Get(), section->GetName().GetStringRef()))
+  if (result == 0 || !(section->Get() & llvm::ELF::SHF_COMPRESSED))
 return result;
 
   auto Decompressor = llvm::object::Decompressor::create(

diff  --git a/lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml 
b/lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
index e252713210e62..d4d289954801a 100644
--- a/lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
+++ b/lldb/test/Shell/ObjectFile/ELF/compressed-sections.yaml
@@ -16,6 +16,7 @@ Sections:
 Type:SHT_PROGBITS
 Flags:   [ SHF_COMPRESSED ]
 Content: deadbeefbaadf00d
+## The legacy .zdebug format is not supported.
   - Name:.zdebug_info
 Type:SHT_PROGBITS
 Content: 5A4C49420008789c533070084828689809c802c1
@@ -37,8 +38,8 @@ Sections:
 # CHECK-NEXT: Data: ()
 
 # CHECK: Name: .zdebug_info
-# CHECK: dwarf-info
+# CHECK: regular
 # CHECK: File size: 28
 # CHECK: Data: (
-# CHECK-NEXT: 20304050 60708090
+# CHECK-NEXT: 5A4C4942  0008 789C5330 70084828 6898 09C802C1
 # CHECK-NEXT: )

diff  --git a/lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml 
b/lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml
deleted file mode 100644
index 069753835474b..0
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/gnu-style-compression.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-## NB: This is a yaml file because llvm gnu-style writing support in 14.0
-## (2022, D117744). In due time we may want to remove it from lldb as well.
-
-## Debug info generated from the following sources using clang-13
-## struct A {
-##  long a = 42;
-## };
-## extern constexpr short s = 47;
-## extern constexpr A a{};
-
-# REQUIRES: zlib
-
-# RUN: yaml2obj %s > %t
-# RUN: %lldb %t -o "target var s a" -b | FileCheck %s
-
-# CHECK: (const short) s = 47
-# CHECK: (const A) a = (a = 42)
-
 !ELF
-FileHeader:
-  Class:   ELFCLASS64
-  Data:ELFDATA2LSB
-  Type:ET_EXEC
-  Machine: EM_X86_64
-  Entry:   0x401000
-Sections:
-  - Name:.rodata
-Type:SHT_PROGBITS
-Flags:   [ SHF_ALLOC ]
-Address: 0x401000
-AddressAlign:0x8
-Offset:  0x1000
-Content: 2F002A00
-  - Name:.zdebug_info
-Type:SHT_PROGBITS
-AddressAlign:0x1
-Content: 
5A4C49420077789C2B666060606100010E4610A9C820CA00012640CCE407248C81989197939941C0012CC16C01D2130024589998C280540848011F2733074C4124488E35116C28171B48493E480937505B04488A830100368605A7
-  - Name:.debug_abbrev
-Type:SHT_PROGBITS
-AddressAlign:0x1
-Content: 
011101250E1305030E10171B0E023400030E49133F193A0B3B0B02180326004913042400030E3E0B0B0B051301360B030E0B0B3A0B3B0B060D00030E49133A0B3B0B380B00
-  - Name: 

[Lldb-commits] [PATCH] D128710: [lldb] [llgs] Fix multi-resume bugs with nonstop mode

[Michał Górny via Phabricator via lldb-commits]

mgorny updated this revision to Diff 444696.
mgorny added a comment.

Remove support for `t` with individual thread numbers and simplify code. Move 
resuming the process (and checking whether it can be resumed) into a common 
`ResumeProcess()` method.


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

https://reviews.llvm.org/D128710

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/test/API/tools/lldb-server/TestNonStop.py
  lldb/test/API/tools/lldb-server/vCont-threads/TestPartialResume.py

Index: lldb/test/API/tools/lldb-server/vCont-threads/TestPartialResume.py
===
--- lldb/test/API/tools/lldb-server/vCont-threads/TestPartialResume.py
+++ lldb/test/API/tools/lldb-server/vCont-threads/TestPartialResume.py
@@ -75,54 +75,3 @@
 main_thread,
 "c:{:x};c:{:x};t".format(*all_subthreads_list[:2])),
 set(all_subthreads_list[:2]))
-
-@skipIfWindows
-@add_test_categories(["llgs"])
-def test_vCont_txc(self):
-main_thread, all_subthreads_list = (
-self.start_vCont_run_subset_of_threads_test())
-# stop one thread explicitly, resume others
-self.assertEqual(
-self.continue_and_get_threads_running(
-main_thread,
-"t:{:x};c".format(all_subthreads_list[-1])),
-set(all_subthreads_list[:2]))
-
-@skipIfWindows
-@add_test_categories(["llgs"])
-def test_vCont_cxtxc(self):
-main_thread, all_subthreads_list = (
-self.start_vCont_run_subset_of_threads_test())
-# resume one thread explicitly, stop one explicitly,
-# resume others
-self.assertEqual(
-self.continue_and_get_threads_running(
-main_thread,
-"c:{:x};t:{:x};c".format(*all_subthreads_list[-2:])),
-set(all_subthreads_list[:2]))
-
-@skipIfWindows
-@add_test_categories(["llgs"])
-def test_vCont_txcx(self):
-main_thread, all_subthreads_list = (
-self.start_vCont_run_subset_of_threads_test())
-# resume one thread explicitly, stop one explicitly,
-# stop others implicitly
-self.assertEqual(
-self.continue_and_get_threads_running(
-main_thread,
-"t:{:x};c:{:x}".format(*all_subthreads_list[:2])),
-set(all_subthreads_list[1:2]))
-
-@skipIfWindows
-@add_test_categories(["llgs"])
-def test_vCont_txcxt(self):
-main_thread, all_subthreads_list = (
-self.start_vCont_run_subset_of_threads_test())
-# resume one thread explicitly, stop one explicitly,
-# stop others explicitly
-self.assertEqual(
-self.continue_and_get_threads_running(
-main_thread,
-"t:{:x};c:{:x};t".format(*all_subthreads_list[:2])),
-set(all_subthreads_list[1:2]))
Index: lldb/test/API/tools/lldb-server/TestNonStop.py
===
--- lldb/test/API/tools/lldb-server/TestNonStop.py
+++ lldb/test/API/tools/lldb-server/TestNonStop.py
@@ -168,3 +168,137 @@
  "send packet: $OK#00",
  ], True)
 self.expect_gdbremote_sequence()
+
+def multiple_resume_test(self, second_command):
+self.build()
+self.set_inferior_startup_launch()
+procs = self.prep_debug_monitor_and_inferior(
+inferior_args=["sleep:15"])
+self.test_sequence.add_log_lines(
+["read packet: $QNonStop:1#00",
+ "send packet: $OK#00",
+ "read packet: $c#63",
+ "send packet: $OK#00",
+ "read packet: ${}#00".format(second_command),
+ "send packet: $E37#00",
+ ], True)
+self.expect_gdbremote_sequence()
+
+@add_test_categories(["llgs"])
+def test_multiple_C(self):
+self.multiple_resume_test("C05")
+
+@add_test_categories(["llgs"])
+def test_multiple_c(self):
+self.multiple_resume_test("c")
+
+@add_test_categories(["llgs"])
+def test_multiple_s(self):
+self.multiple_resume_test("s")
+
+@expectedFailureAll(archs=["arm"])  # TODO
+@expectedFailureAll(archs=["aarch64"],
+bugnumber="https://github.com/llvm/llvm-project/issues/56268;)
+@add_test_categories(["llgs"])
+def test_multiple_vCont(self):
+self.build()
+self.set_inferior_startup_launch()
+procs = self.prep_debug_monitor_and_inferior(
+inferior_args=["thread:new", "trap", "sleep:15"])
+self.test_sequence.add_log_lines(
+["read packet: $QNonStop:1#00",
+ "send packet: $OK#00",
+ "read packet: $c#63",
+ "send packet: $OK#00",
+ 

[Lldb-commits] [PATCH] D81471: [lldb] Add support for using integral const static data members in the expression evaluator

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

Looks like this broke the Windows lldb bot as well: 
https://lab.llvm.org/buildbot/#/builders/83/builds/21186


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81471

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

[Lldb-commits] [PATCH] D129078: [LLDB][ClangExpression] Allow expression evaluation from within C++ Lambdas

[Michael Buch via Phabricator via lldb-commits]

Michael137 added a comment.

After playing around with this some more I found an edge case with conditional 
breakpoints (in fact any place where we reuse an LLVMUserExpression). Modifying 
`lldb/test/API/functionalities/breakpoint/two_hits_one_actual` such that the 
helper method is inside a lambda like so:

  struct Foo {
void usleep_helper(int usec) {
  [this, ] {
  // Break here in the helper
  std::this_thread::sleep_for(std::chrono::duration(usec));
  }();
}
  };
  
  void *background_thread(void *arg) {
  (void) arg;
  Foo f;
  for (;;) {
  f.usleep_helper(2);
  }
  }
  
  int main(void) {
std::thread main_thread(background_thread, nullptr);
Foo f;
for (;;) {
  f.usleep_helper(1);
}
  }

Then setting a breakpoint twice, one for `usec == 1` and `usec == 100`, we 
would end up hitting the breakpoint even if `usec == 2` because conditional 
breakpoints re-use Materializer (and thus Entity objects). Since 
`EntityValueObject::GetValueObject` simply returns the ValueObject it was 
instantiated with, the `usec == 1` condition always evaluates to `true`. Have a 
fix for this but verifying whether that really is the best approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129078

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

[Lldb-commits] [PATCH] D129377: [lldb/Fuzzer] Add fuzzer for expression evaluator

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/tools/lldb-fuzzer/lldb-expression-fuzzer/cxx_proto.proto:1
+//===-- cxx_proto.proto - Protobuf description of C++ 
-===//
+//

Do we still need a copy of this for LLDB?


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

https://reviews.llvm.org/D129377

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

[Lldb-commits] [PATCH] D129783: [lldb] Skip tests using int128 on ARM

[Andy Yankovsky via Phabricator via lldb-commits]

werat created this revision.
werat added a reviewer: Michael137.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
werat requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Follow-up fix for https://reviews.llvm.org/D81471.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129783

Files:
  
lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py


Index: 
lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
===
--- 
lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
+++ 
lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
@@ -12,6 +12,8 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
+# uint128_t not available on arm.
+@skipIf(archs=["arm", "aarch64"])
 def test_int128(self):
 self.build()
 lldbutil.run_to_source_breakpoint(self, "// break here",


Index: lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
===
--- lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
+++ lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
@@ -12,6 +12,8 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
+# uint128_t not available on arm.
+@skipIf(archs=["arm", "aarch64"])
 def test_int128(self):
 self.build()
 lldbutil.run_to_source_breakpoint(self, "// break here",
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 4867872 - [lldb] Add support for using integral const static data members in the expression evaluator

[Andy Yankovsky via lldb-commits]

Author: Andy Yankovsky
Date: 2022-07-14T15:15:11Z
New Revision: 486787210df5ce5eabadc90a7de353ae81101feb

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

LOG: [lldb] Add support for using integral const static data members in the 
expression evaluator

This adds support for using const static integral data members as described by 
C++11 [class.static.data]p3
to LLDB's expression evaluator.

So far LLDB treated these data members are normal static variables. They 
already work as intended when they are declared in the class definition and 
then defined in a namespace scope. However, if they are declared and 
initialised in the class definition but never defined in a namespace scope, all 
LLDB expressions that use them will fail to link when LLDB can't find the 
respective symbol for the variable.

The reason for this is that the data members which are only declared in the 
class are not emitted into any object file so LLDB can never resolve them. 
Expressions that use these variables are expected to directly use their 
constant value if possible. Clang can do this for us during codegen, but it 
requires that we add the constant value to the VarDecl we generate for these 
data members.

This patch implements this by:
* parsing the constant values from the debug info and adding it to variable 
declarations we encounter.
* ensuring that LLDB doesn't implicitly try to take the address of expressions 
that might be an lvalue that points to such a special data member.

The second change is caused by LLDB's way of storing lvalues in the expression 
parser. When LLDB parses an expression, it tries to keep the result around via 
two mechanisms:

1. For lvalues, LLDB generates a static pointer variable and stores the address 
of the last expression in it: `T *$__lldb_expr_result_ptr = `
2. For everything else, LLDB generates a static variable of the same type as 
the last expression and then direct initialises that variable: `T 
$__lldb_expr_result(LastExpression)`

If we try to print a special const static data member via something like `expr 
Class::Member`, then LLDB will try to take the address of this expression as 
it's an lvalue. This means LLDB will try to take the address of the variable 
which causes that Clang can't replace the use with the constant value. There 
isn't any good way to detect this case (as there a lot of different expressions 
that could yield an lvalue that points to such a data member), so this patch 
also changes that we only use the first way of capturing the result if the last 
expression does not have a type that could potentially indicate it's coming 
from such a special data member.

This change shouldn't break most workflows for users. The only observable side 
effect I could find is that the implicit persistent result variables for const 
int's now have their own memory address:

Before this change:
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x7ffeefbff8e8
(lldb) p 
(const int *) $2 = 0x7ffeefbff8e8
```

After this change we capture `i` by value so it has its own value.
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x000100155320
(lldb) p 
(const int *) $2 = 0x7ffeefbff8e8
```

Reviewed By: Michael137

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

Added: 
lldb/test/API/lang/cpp/const_static_integral_member/Makefile

lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
lldb/test/API/lang/cpp/const_static_integral_member_int128/Makefile

lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
lldb/test/API/lang/cpp/const_static_integral_member_int128/main.cpp

Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
index 7a1ac78705474..799ae29e2841c 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
@@ -197,6 +197,27 @@ bool ASTResultSynthesizer::SynthesizeObjCMethodResult(
   return ret;
 }
 
+/// Returns true if LLDB can take the address of the given lvalue for the sake
+/// of capturing the expression result. Returns false if LLDB should instead
+/// store the expression result in a result 

[Lldb-commits] [PATCH] D81471: [lldb] Add support for using integral const static data members in the expression evaluator

[Andy Yankovsky via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG486787210df5: [lldb] Add support for using integral const 
static data members in the… (authored by werat).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81471

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
  lldb/test/API/lang/cpp/const_static_integral_member/Makefile
  
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
  lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
  lldb/test/API/lang/cpp/const_static_integral_member_int128/Makefile
  
lldb/test/API/lang/cpp/const_static_integral_member_int128/TestConstStaticIntegralMemberInt128.py
  lldb/test/API/lang/cpp/const_static_integral_member_int128/main.cpp
  lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
  lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp

Index: lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
===
--- lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
+++ lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
@@ -273,3 +273,128 @@
   };
   ASSERT_EQ(found_function_types, expected_function_types);
 }
+
+struct ExtractIntFromFormValueTest : public testing::Test {
+  SubsystemRAII subsystems;
+  TypeSystemClang ts;
+  DWARFASTParserClang parser;
+  ExtractIntFromFormValueTest()
+  : ts("dummy ASTContext", HostInfoBase::GetTargetTriple()), parser(ts) {}
+
+  /// Takes the given integer value, stores it in a DWARFFormValue and then
+  /// tries to extract the value back via
+  /// DWARFASTParserClang::ExtractIntFromFormValue.
+  /// Returns the string representation of the extracted value or the error
+  /// that was returned from ExtractIntFromFormValue.
+  llvm::Expected Extract(clang::QualType qt, uint64_t value) {
+DWARFFormValue form_value;
+form_value.SetUnsigned(value);
+llvm::Expected result =
+parser.ExtractIntFromFormValue(ts.GetType(qt), form_value);
+if (!result)
+  return result.takeError();
+llvm::SmallString<16> result_str;
+result->toStringUnsigned(result_str);
+return std::string(result_str.str());
+  }
+
+  /// Same as ExtractIntFromFormValueTest::Extract but takes a signed integer
+  /// and treats the result as a signed integer.
+  llvm::Expected ExtractS(clang::QualType qt, int64_t value) {
+DWARFFormValue form_value;
+form_value.SetSigned(value);
+llvm::Expected result =
+parser.ExtractIntFromFormValue(ts.GetType(qt), form_value);
+if (!result)
+  return result.takeError();
+llvm::SmallString<16> result_str;
+result->toStringSigned(result_str);
+return std::string(result_str.str());
+  }
+};
+
+TEST_F(ExtractIntFromFormValueTest, TestBool) {
+  using namespace llvm;
+  clang::ASTContext  = ts.getASTContext();
+
+  EXPECT_THAT_EXPECTED(Extract(ast.BoolTy, 0), HasValue("0"));
+  EXPECT_THAT_EXPECTED(Extract(ast.BoolTy, 1), HasValue("1"));
+  EXPECT_THAT_EXPECTED(Extract(ast.BoolTy, 2), Failed());
+  EXPECT_THAT_EXPECTED(Extract(ast.BoolTy, 3), Failed());
+}
+
+TEST_F(ExtractIntFromFormValueTest, TestInt) {
+  using namespace llvm;
+
+  clang::ASTContext  = ts.getASTContext();
+
+  // Find the min/max values for 'int' on the current host target.
+  constexpr int64_t int_max = std::numeric_limits::max();
+  constexpr int64_t int_min = std::numeric_limits::min();
+
+  // Check that the bit width of int matches the int width in our type system.
+  ASSERT_EQ(sizeof(int) * 8, ast.getIntWidth(ast.IntTy));
+
+  // Check values around int_min.
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_min - 2), llvm::Failed());
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_min - 1), llvm::Failed());
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_min),
+   HasValue(std::to_string(int_min)));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_min + 1),
+   HasValue(std::to_string(int_min + 1)));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_min + 2),
+   HasValue(std::to_string(int_min + 2)));
+
+  // Check values around 0.
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, -128), HasValue("-128"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, -10), HasValue("-10"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, -1), HasValue("-1"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, 0), HasValue("0"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, 1), HasValue("1"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, 10), HasValue("10"));
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, 128), HasValue("128"));
+
+  // Check values around int_max.
+  EXPECT_THAT_EXPECTED(ExtractS(ast.IntTy, int_max - 2),
+   

[Lldb-commits] [PATCH] D129652: [lldb] [llgs] Convert m_debugged_processes into a map of structs

[Michał Górny via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG355c7916336f: [lldb] [llgs] Convert m_debugged_processes 
into a map of structs (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129652

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h

Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -85,6 +85,17 @@
 
   Status InitializeConnection(std::unique_ptr connection);
 
+  struct DebuggedProcess {
+enum class Flag {
+  vkilled = (1u << 0),
+
+  LLVM_MARK_AS_BITMASK_ENUM(vkilled)
+};
+
+std::unique_ptr process_up;
+Flag flags;
+  };
+
 protected:
   MainLoop _mainloop;
   MainLoop::ReadHandleUP m_network_handle_up;
@@ -94,9 +105,7 @@
   NativeProcessProtocol *m_current_process;
   NativeProcessProtocol *m_continue_process;
   std::recursive_mutex m_debugged_process_mutex;
-  std::unordered_map>
-  m_debugged_processes;
-  std::unordered_set m_vkilled_processes;
+  std::unordered_map m_debugged_processes;
 
   Communication m_stdio_communication;
   MainLoop::ReadHandleUP m_stdio_handle_up;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -290,7 +290,9 @@
 if (!process_or)
   return Status(process_or.takeError());
 m_continue_process = m_current_process = process_or->get();
-m_debugged_processes[m_current_process->GetID()] = std::move(*process_or);
+m_debugged_processes.emplace(
+m_current_process->GetID(),
+DebuggedProcess{std::move(*process_or), DebuggedProcess::Flag{}});
   }
 
   SetEnabledExtensions(*m_current_process);
@@ -361,7 +363,9 @@
 return status;
   }
   m_continue_process = m_current_process = process_or->get();
-  m_debugged_processes[m_current_process->GetID()] = std::move(*process_or);
+  m_debugged_processes.emplace(
+  m_current_process->GetID(),
+  DebuggedProcess{std::move(*process_or), DebuggedProcess::Flag{}});
   SetEnabledExtensions(*m_current_process);
 
   // Setup stdout/stderr mapping from inferior.
@@ -489,12 +493,14 @@
*wait_status);
 
   // If the process was killed through vKill, return "OK".
-  if (m_vkilled_processes.find(process->GetID()) != m_vkilled_processes.end())
+  if (bool(m_debugged_processes.at(process->GetID()).flags &
+   DebuggedProcess::Flag::vkilled))
 return SendOKResponse();
 
   StreamGDBRemote response;
   response.Format("{0:g}", *wait_status);
-  if (bool(m_extensions_supported & NativeProcessProtocol::Extension::multiprocess))
+  if (bool(m_extensions_supported &
+   NativeProcessProtocol::Extension::multiprocess))
 response.Format(";process:{0:x-}", process->GetID());
   if (m_non_stop)
 return SendNotificationPacketNoLock("Stop", m_stop_notification_queue,
@@ -1045,14 +1051,14 @@
 
   lldb::pid_t pid = process->GetID();
   m_mainloop.AddPendingCallback([this, pid](MainLoopBase ) {
-m_debugged_processes.erase(pid);
-auto vkill_it = m_vkilled_processes.find(pid);
-if (vkill_it != m_vkilled_processes.end())
-  m_vkilled_processes.erase(vkill_it);
+auto find_it = m_debugged_processes.find(pid);
+assert(find_it != m_debugged_processes.end());
+bool vkilled = bool(find_it->second.flags & DebuggedProcess::Flag::vkilled);
+m_debugged_processes.erase(find_it);
 // Terminate the main loop only if vKill has not been used.
 // When running in non-stop mode, wait for the vStopped to clear
 // the notification queue.
-else if (m_debugged_processes.empty() && !m_non_stop) {
+if (m_debugged_processes.empty() && !m_non_stop && !vkilled) {
   // Close the pipe to the inferior terminal i/o if we launched it and set
   // one up.
   MaybeCloseInferiorTerminalConnection();
@@ -1147,7 +1153,9 @@
   lldb::pid_t child_pid = child_process->GetID();
   assert(child_pid != LLDB_INVALID_PROCESS_ID);
   assert(m_debugged_processes.find(child_pid) == m_debugged_processes.end());
-  m_debugged_processes[child_pid] = std::move(child_process);
+  m_debugged_processes.emplace(
+  child_pid,
+  DebuggedProcess{std::move(child_process), DebuggedProcess::Flag{}});
 }
 
 void GDBRemoteCommunicationServerLLGS::DataAvailableCallback() {
@@ -1432,7 +1440,7 @@
   for (auto it = m_debugged_processes.begin(); it != 

[Lldb-commits] [lldb] 355c791 - [lldb] [llgs] Convert m_debugged_processes into a map of structs

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2022-07-14T15:32:19+02:00
New Revision: 355c7916336fb4922946a8cfc174dbdb514dddb5

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

LOG: [lldb] [llgs] Convert m_debugged_processes into a map of structs

Convert the m_debugged_processes map from NativeProcessProtocol pointers
to structs, and combine the additional set(s) holding the additional
process properties into a flag field inside this struct.  This is
desirable since there are more properties to come and having a single
structure with all information should be cleaner and more efficient than
using multiple sets for that.

Suggested by Pavel Labath in D128893.

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

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 63174ef55219..7ddb4c80e16d 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -290,7 +290,9 @@ Status GDBRemoteCommunicationServerLLGS::LaunchProcess() {
 if (!process_or)
   return Status(process_or.takeError());
 m_continue_process = m_current_process = process_or->get();
-m_debugged_processes[m_current_process->GetID()] = std::move(*process_or);
+m_debugged_processes.emplace(
+m_current_process->GetID(),
+DebuggedProcess{std::move(*process_or), DebuggedProcess::Flag{}});
   }
 
   SetEnabledExtensions(*m_current_process);
@@ -361,7 +363,9 @@ Status 
GDBRemoteCommunicationServerLLGS::AttachToProcess(lldb::pid_t pid) {
 return status;
   }
   m_continue_process = m_current_process = process_or->get();
-  m_debugged_processes[m_current_process->GetID()] = std::move(*process_or);
+  m_debugged_processes.emplace(
+  m_current_process->GetID(),
+  DebuggedProcess{std::move(*process_or), DebuggedProcess::Flag{}});
   SetEnabledExtensions(*m_current_process);
 
   // Setup stdout/stderr mapping from inferior.
@@ -489,12 +493,14 @@ GDBRemoteCommunicationServerLLGS::SendWResponse(
*wait_status);
 
   // If the process was killed through vKill, return "OK".
-  if (m_vkilled_processes.find(process->GetID()) != m_vkilled_processes.end())
+  if (bool(m_debugged_processes.at(process->GetID()).flags &
+   DebuggedProcess::Flag::vkilled))
 return SendOKResponse();
 
   StreamGDBRemote response;
   response.Format("{0:g}", *wait_status);
-  if (bool(m_extensions_supported & 
NativeProcessProtocol::Extension::multiprocess))
+  if (bool(m_extensions_supported &
+   NativeProcessProtocol::Extension::multiprocess))
 response.Format(";process:{0:x-}", process->GetID());
   if (m_non_stop)
 return SendNotificationPacketNoLock("Stop", m_stop_notification_queue,
@@ -1045,14 +1051,14 @@ void 
GDBRemoteCommunicationServerLLGS::HandleInferiorState_Exited(
 
   lldb::pid_t pid = process->GetID();
   m_mainloop.AddPendingCallback([this, pid](MainLoopBase ) {
-m_debugged_processes.erase(pid);
-auto vkill_it = m_vkilled_processes.find(pid);
-if (vkill_it != m_vkilled_processes.end())
-  m_vkilled_processes.erase(vkill_it);
+auto find_it = m_debugged_processes.find(pid);
+assert(find_it != m_debugged_processes.end());
+bool vkilled = bool(find_it->second.flags & 
DebuggedProcess::Flag::vkilled);
+m_debugged_processes.erase(find_it);
 // Terminate the main loop only if vKill has not been used.
 // When running in non-stop mode, wait for the vStopped to clear
 // the notification queue.
-else if (m_debugged_processes.empty() && !m_non_stop) {
+if (m_debugged_processes.empty() && !m_non_stop && !vkilled) {
   // Close the pipe to the inferior terminal i/o if we launched it and set
   // one up.
   MaybeCloseInferiorTerminalConnection();
@@ -1147,7 +1153,9 @@ void GDBRemoteCommunicationServerLLGS::NewSubprocess(
   lldb::pid_t child_pid = child_process->GetID();
   assert(child_pid != LLDB_INVALID_PROCESS_ID);
   assert(m_debugged_processes.find(child_pid) == m_debugged_processes.end());
-  m_debugged_processes[child_pid] = std::move(child_process);
+  m_debugged_processes.emplace(
+  child_pid,
+  DebuggedProcess{std::move(child_process), DebuggedProcess::Flag{}});
 }
 
 void GDBRemoteCommunicationServerLLGS::DataAvailableCallback() {
@@ -1432,7 +1440,7 @@ 
GDBRemoteCommunicationServerLLGS::Handle_k(StringExtractorGDBRemote ) {
   for (auto it = m_debugged_processes.begin(); it 

[Lldb-commits] [PATCH] D129750: [lldb] Always use APFloat for FP dumping

[David Spickett via Phabricator via lldb-commits]

DavidSpickett accepted this revision.
DavidSpickett added a comment.
This revision is now accepted and ready to land.

I'm no float expert but seems fine. Also checked on AArch64 and no failures 
there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129750

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

[Lldb-commits] [PATCH] D128710: [lldb] [llgs] Fix multi-resume bugs with nonstop mode

[Michał Górny via Phabricator via lldb-commits]

mgorny added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1818-1821
+// 4. vCont on a running process that requests suspending a subset
+//of running threads or resuming a subset of suspended threads.
+//Since we do not support full nonstop mode, this is unsupported
+//and we return an error.

labath wrote:
> I think this is going to be racy if new threads appear before we are able to 
> stop everything. I mean that in the sense that if the client has listed all 
> (known) threads of the process explicitly, and a new thread appears before 
> we're able to act on it, then (I guess) the expected behavior would be to 
> keep that thread running (but we won't do that). 
> 
> Do we need to support this kind of stopping right now? Maybe we could only 
> support the `pid.-1` syntax for stopping all threads within a process? (which 
> should also make the `ResumeActionListStopsAllThreads` logic simpler)
No, I don't think we need to support it. I'll remove it then and simplify the 
logic.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3003-3010
+  // In non-stop protocol mode, the process could be running already.
+  // We do not support resuming threads independently, so just error out.
+  if (!m_continue_process->CanResume()) {
+LLDB_LOG(log, "process cannot be resumed (state={0})",
+ m_continue_process->GetState());
+return SendErrorResponse(0x37);
+  }

labath wrote:
> Could we factor even more of these functions into a common place? If we e.g. 
> moved this block right before the `m_continue_process->Resume`, then we could 
> put it, and into a helper function.
Makes sense.


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

https://reviews.llvm.org/D128710

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

[Lldb-commits] [PATCH] D128893: [lldb] [llgs] Fix disabling non-stop mode

[Michał Górny via Phabricator via lldb-commits]

mgorny added a comment.

Hmm, I suppose that makes sense.


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

https://reviews.llvm.org/D128893

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

[Lldb-commits] [PATCH] D129652: [lldb] [llgs] Convert m_debugged_processes into a map of structs

[Michał Górny via Phabricator via lldb-commits]

mgorny added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1058-1060
 // Terminate the main loop only if vKill has not been used.
 // When running in non-stop mode, wait for the vStopped to clear
 // the notification queue.

labath wrote:
> Btw, is this actually correct. E.g. I don't think we ought to terminate the 
> connection if a process dies "naturally", and there are still other processes 
> around...
> 
> Isn't it more like the opposite, that if `k` is used, *then* we close the 
> connection (after all processes exit)? And maybe also when the process exits, 
> and multiprocess extensions are disabled?
Well, the comment describes some of the cases when we don't terminate it, i.e. 
it skips the kinda-obvious case when there are additional processes running, 
i.e. we stop it only if all of the following apply: a. all processes have 
exited, b. we are not in non-stop mode (in non-stop mode we wait for 
`vStopped`) and c. the last process wasn't killed by `vKill` (to match the 
behavior of GDB).


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

https://reviews.llvm.org/D129652

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

[Lldb-commits] [PATCH] D129489: [lldb][AArch64] Add support for memory tags in core files

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 444628.
DavidSpickett added a comment.

Add a release note.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129489

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
  
lldb/test/API/linux/aarch64/mte_core_file/TestAArch64LinuxMTEMemoryTagCoreFile.py
  lldb/test/API/linux/aarch64/mte_core_file/core.mte
  lldb/test/API/linux/aarch64/mte_core_file/core.nomte
  lldb/test/API/linux/aarch64/mte_core_file/main.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/BinaryFormat/ELF.h

Index: llvm/include/llvm/BinaryFormat/ELF.h
===
--- llvm/include/llvm/BinaryFormat/ELF.h
+++ llvm/include/llvm/BinaryFormat/ELF.h
@@ -1366,6 +1366,8 @@
   // These all contain stack unwind tables.
   PT_ARM_EXIDX = 0x7001,
   PT_ARM_UNWIND = 0x7001,
+  // MTE memory tag segment type
+  PT_AARCH64_MEMTAG_MTE = 0x7002,
 
   // MIPS program header types.
   PT_MIPS_REGINFO = 0x7000,  // Register usage information.
Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -275,6 +275,8 @@
 locations. This prevents us reading locations multiple times, or not
 writing out new values if the addresses have different non-address bits.
 
+* LLDB now supports reading memory tags from AArch64 Linux core files.
+
 Changes to Sanitizers
 -
 
Index: lldb/test/API/linux/aarch64/mte_core_file/main.c
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/mte_core_file/main.c
@@ -0,0 +1,78 @@
+// Program to generate core files to test MTE tag features.
+//
+// This file uses ACLE intrinsics as detailed in:
+// https://developer.arm.com/documentation/101028/0012/10--Memory-tagging-intrinsics?lang=en
+//
+// Compile with:
+//  -march=armv8.5-a+memtag -g main.c -o a.out.mte
+//  -march=armv8.5-a+memtag -g main.c -DNO_MTE -o a.out.nomte
+//
+// /proc/self/coredump_filter was set to 2 when the core files were made.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char const *argv[]) {
+#ifdef NO_MTE
+  *(char *)(0) = 0;
+#endif
+
+  if (prctl(PR_SET_TAGGED_ADDR_CTRL,
+PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC |
+// Allow all tags to be generated by the addg
+// instruction __arm_mte_increment_tag produces.
+(0x << PR_MTE_TAG_SHIFT),
+0, 0, 0)) {
+return 1;
+  }
+
+  size_t page_size = sysconf(_SC_PAGESIZE);
+  char *mte_buf = mmap(0, page_size, PROT_READ | PROT_WRITE | PROT_MTE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (!mte_buf)
+return 1;
+
+  printf("mte_buf: %p\n", mte_buf);
+
+  // Allocate some untagged memory before the tagged memory.
+  char *buf = mmap(0, page_size, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (!buf)
+return 1;
+
+  printf("buf: %p\n", buf);
+
+  // This write means that the memory for buf is included in the corefile.
+  // So we can read from the end of it into mte_buf during the test.
+  *buf = 1;
+
+  // These must be next to each other for the tests to work.
+  // 
+  // mte_buf
+  // buf
+  // 
+  if ((mte_buf - buf) != page_size) {
+return 1;
+  }
+
+  // Set incrementing tags until end of the page.
+  char *tagged_ptr = mte_buf;
+  // This ignores tag bits when subtracting the addresses.
+  while (__arm_mte_ptrdiff(tagged_ptr, mte_buf) < page_size) {
+// Set the allocation tag for this location.
+__arm_mte_set_tag(tagged_ptr);
+// + 16 for 16 byte granules.
+// Earlier we allowed all tag values, so this will give us an
+// incrementing pattern 0-0xF wrapping back to 0.
+tagged_ptr = __arm_mte_increment_tag(tagged_ptr + 16, 1);
+  }
+
+  // Will fault because logical tag 0 != allocation tag 1.
+  *(mte_buf + 16) = 1;
+
+  return 0;
+}
Index: lldb/test/API/linux/aarch64/mte_core_file/TestAArch64LinuxMTEMemoryTagCoreFile.py
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/mte_core_file/TestAArch64LinuxMTEMemoryTagCoreFile.py
@@ -0,0 +1,170 @@
+"""
+Test that memory tagging features work with Linux core files.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class AArch64LinuxMTEMemoryTagCoreFileTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+NO_DEBUG_INFO_TESTCASE = True
+
+MTE_BUF_ADDR = hex(0x82c74000)
+BUF_ADDR = hex(0x82c73000)
+
+@skipIfLLVMTargetMissing("AArch64")
+def test_mte_tag_core_file_memory_region(self):
+""" Test 

[Lldb-commits] [PATCH] D128710: [lldb] [llgs] Fix multi-resume bugs with nonstop mode

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1818-1821
+// 4. vCont on a running process that requests suspending a subset
+//of running threads or resuming a subset of suspended threads.
+//Since we do not support full nonstop mode, this is unsupported
+//and we return an error.

I think this is going to be racy if new threads appear before we are able to 
stop everything. I mean that in the sense that if the client has listed all 
(known) threads of the process explicitly, and a new thread appears before 
we're able to act on it, then (I guess) the expected behavior would be to keep 
that thread running (but we won't do that). 

Do we need to support this kind of stopping right now? Maybe we could only 
support the `pid.-1` syntax for stopping all threads within a process? (which 
should also make the `ResumeActionListStopsAllThreads` logic simpler)



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3003-3010
+  // In non-stop protocol mode, the process could be running already.
+  // We do not support resuming threads independently, so just error out.
+  if (!m_continue_process->CanResume()) {
+LLDB_LOG(log, "process cannot be resumed (state={0})",
+ m_continue_process->GetState());
+return SendErrorResponse(0x37);
+  }

Could we factor even more of these functions into a common place? If we e.g. 
moved this block right before the `m_continue_process->Resume`, then we could 
put it, and into a helper function.


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

https://reviews.llvm.org/D128710

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

[Lldb-commits] [PATCH] D81471: [lldb] Add support for using integral const static data members in the expression evaluator

[Andy Yankovsky via Phabricator via lldb-commits]

werat edited reviewers, added: Michael137; removed: jarin.
werat added a comment.

In D81471#3641915 , @labath wrote:

> So, if noone objects to this, then I think it's fine.

I guess nobody objects :)

@labath, @Michael137, can you accept/LGTM the revision?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81471

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

[Lldb-commits] [PATCH] D129750: [lldb] Always use APFloat for FP dumping

[Emmmer S via Phabricator via lldb-commits]

Emmmer added a comment.

On the riscv64 platform, LLDBCoreTests passed after applying this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129750

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

[Lldb-commits] [PATCH] D129736: [lldb] Skip a float16 NaN test for RISC-V

[Emmmer S via Phabricator via lldb-commits]

Emmmer abandoned this revision.
Emmmer added a comment.

Superseded by D129750 , which introduced a 
platform independent way of checking floating point test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129736

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

[Lldb-commits] [PATCH] D128893: [lldb] [llgs] Fix disabling non-stop mode

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Actually, on second thought (:D) do we even need a per-process flag for this?

Turning off non-stop should stop _all_ processes, so instead of checking 
whether there are any processes with the 'stopping-due-to-qnonstop` flag 
around, couldn't we just check if we have any unstopped processes altogether?

(This will require a global `qnonstop-in-progress` flag, but that's still 
better than a per-process flag.)


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

https://reviews.llvm.org/D128893

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

[Lldb-commits] [PATCH] D129652: [lldb] [llgs] Convert m_debugged_processes into a map of structs

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1058-1060
 // Terminate the main loop only if vKill has not been used.
 // When running in non-stop mode, wait for the vStopped to clear
 // the notification queue.

Btw, is this actually correct. E.g. I don't think we ought to terminate the 
connection if a process dies "naturally", and there are still other processes 
around...

Isn't it more like the opposite, that if `k` is used, *then* we close the 
connection (after all processes exit)? And maybe also when the process exits, 
and multiprocess extensions are disabled?


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

https://reviews.llvm.org/D129652

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

[Lldb-commits] [PATCH] D129736: [lldb] Skip a float16 NaN test for RISC-V

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

That code is horrible. Lemme see if I can remove it (=> D129750 
). If that doesn't work, then we can try 
skipping this...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129736

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

[Lldb-commits] [PATCH] D129750: [lldb] Always use APFloat for FP dumping

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: JDevlieghere, jingham, DavidSpickett, Emmmer.
Herald added subscribers: jsji, pengfei.
Herald added a project: All.
labath requested review of this revision.
Herald added a project: LLDB.

The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could query it for the appropriate semantics. If we didn't
have a Target, we used host operations to read and format the value.

This patch changes second path to use APFloat as well. To make it work,
I pick reasonable defaults for different byte size. Notably, I did not
include x87 long double in that list (as it is ambibuous and
architecture-specific). This exposed a bug where we were printing
register values using the target-less branch, even though the registers
definitely belong to a target, and we had it available. Fixing this
prompted the update of several tests for register values due to slightly
different floating point outputs.

The most dubious aspect of this patch is the change in
TypeSystemClang::GetFloatTypeSemantics to recognize `10` as a valid size
for x87 long double. This was necessary because because sizeof(long
double) on x86_64 is 16 even though it only holds 10 bytes of useful
data. This generalizes the hackaround present in the target-free branch
of the dumping function.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129750

Files:
  lldb/include/lldb/Core/DumpRegisterValue.h
  lldb/source/Commands/CommandObjectRegister.cpp
  lldb/source/Core/DumpDataExtractor.cpp
  lldb/source/Core/DumpRegisterValue.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
  lldb/unittests/Core/DumpDataExtractorTest.cpp

Index: lldb/unittests/Core/DumpDataExtractorTest.cpp
===
--- lldb/unittests/Core/DumpDataExtractorTest.cpp
+++ lldb/unittests/Core/DumpDataExtractorTest.cpp
@@ -138,7 +138,7 @@
   TestDump(-1, lldb::Format::eFormatEnum, "-1");
   TestDump(0xcafef00d, lldb::Format::eFormatHex, "0xcafef00d");
   TestDump(0xcafef00d, lldb::Format::eFormatHexUppercase, "0xCAFEF00D");
-  TestDump(0.456, lldb::Format::eFormatFloat, "0.456");
+  TestDump(0.456, lldb::Format::eFormatFloat, "0.45602");
   TestDump(9, lldb::Format::eFormatOctal, "011");
   // Chars packed into an integer.
   TestDump(0x4C4C4442, lldb::Format::eFormatOSType, "'LLDB'");
@@ -180,44 +180,39 @@
lldb::Format::eFormatVectorOfFloat16, "{0 -0}");
   // Some subnormal numbers.
   TestDump(std::vector{0x0001, 0x8001},
-   lldb::Format::eFormatVectorOfFloat16, "{5.96046e-08 -5.96046e-08}");
+   lldb::Format::eFormatVectorOfFloat16, "{5.9605E-8 -5.9605E-8}");
   // A full mantisse and empty expontent.
   TestDump(std::vector{0x83ff, 0x03ff},
-   lldb::Format::eFormatVectorOfFloat16, "{-6.09756e-05 6.09756e-05}");
+   lldb::Format::eFormatVectorOfFloat16, "{-6.0976E-5 6.0976E-5}");
   // Some normal numbers.
   TestDump(std::vector{0b011001001000},
-   lldb::Format::eFormatVectorOfFloat16,
-#if defined(_MSC_VER) && _MSC_VER < 1920
-   // FIXME: This should print the same on all platforms.
-   "{3.14063}");
-#else
-   "{3.14062}");
-#endif
+   lldb::Format::eFormatVectorOfFloat16, "{3.1406}");
   // Largest and smallest normal number.
   TestDump(std::vector{0x0400, 0x7bff},
-   lldb::Format::eFormatVectorOfFloat16, "{6.10352e-05 65504}");
+   lldb::Format::eFormatVectorOfFloat16, "{6.1035E-5 65504}");
   TestDump(std::vector{0xabcd, 0x1234},
-   lldb::Format::eFormatVectorOfFloat16, "{-0.0609436 0.000757217}");
+   lldb::Format::eFormatVectorOfFloat16, "{-0.060944 7.5722E-4}");
 
   // quiet/signaling NaNs.
   TestDump(std::vector{0x, 0xffc0, 0x7fff, 0x7fc0},
-   lldb::Format::eFormatVectorOfFloat16, "{-nan -nan nan nan}");
+   lldb::Format::eFormatVectorOfFloat16, "{NaN NaN NaN NaN}");
   // +/-Inf.
   TestDump(std::vector{0xfc00, 0x7c00},
-   lldb::Format::eFormatVectorOfFloat16, "{-inf inf}");
+   lldb::Format::eFormatVectorOfFloat16, "{-Inf +Inf}");
 
   TestDump(std::vector{std::numeric_limits::min(),
   std::numeric_limits::max()},
-   lldb::Format::eFormatVectorOfFloat32, "{1.17549e-38 3.40282e+38}");
+   lldb::Format::eFormatVectorOfFloat32,
+   "{1.17549435E-38 3.40282347E+38}");
   TestDump(std::vector{std::numeric_limits::quiet_NaN(),
   std::numeric_limits::signaling_NaN(),
   -std::numeric_limits::quiet_NaN(),
   -std::numeric_limits::signaling_NaN()},
-   lldb::Format::eFormatVectorOfFloat32, "{nan nan -nan -nan}");
+   lldb::Format::eFormatVectorOfFloat32, "{NaN NaN 

[Lldb-commits] [PATCH] D129736: [lldb] Skip a float16 NaN test for RISC-V

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

Seems fine to me. Do you have a tracking issue for this? You could just open 
one for "lldb riscv test failures" and add comments as you find more failures. 
So people can see the current state of the test suite.




Comment at: lldb/unittests/Core/DumpDataExtractorTest.cpp:202
 
+#if !defined(__riscv)
   // quiet/signaling NaNs.

Add a brief comment with the reason, "riscv does not support" just a one 
liner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129736

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

[Lldb-commits] [lldb] c164efb - [lldb] [gdb-remote] Remove stray GetSupportsThreadSuffix() method (NFC)

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2022-07-14T12:18:17+02:00
New Revision: c164efb0064682893fc37d6c07e1e000861d7879

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

LOG: [lldb] [gdb-remote] Remove stray GetSupportsThreadSuffix() method (NFC)

Remove stray GDBRemoteCommunicationClient::GetSupportsThreadSuffix()
method that is not implemented nor used anywhere.

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
index 58ed22187747..d367f75cee0e 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
@@ -254,8 +254,6 @@ class GDBRemoteCommunicationClient : public 
GDBRemoteClientBase {
 
   lldb::addr_t GetShlibInfoAddr();
 
-  bool GetSupportsThreadSuffix();
-
   bool GetProcessInfo(lldb::pid_t pid, ProcessInstanceInfo _info);
 
   uint32_t FindProcesses(const ProcessInstanceInfoMatch _match_info,



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

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

[Matheus Izvekov via Phabricator via lldb-commits]

mizvekov added a comment.

In D112374#3650749 , @glandium wrote:

> FWIW, this change also broke this check in Firefox's clang plugin: 
> https://searchfox.org/mozilla-central/rev/0d11f3660945ce35c49501bb44bc4f82bb2b503c/build/clang-plugin/NoPrincipalGetURI.cpp

Thanks for the report!

I think this is a combination of 1) and 2) from above post 
(https://reviews.llvm.org/D112374#3650056).

I believe that hasType(asString()) is supposed to match the type as-written. 
The fact that it did not so for unqualified names is what this patch is fixing.

Can you confirm that this `NoPrincipalGetURI` matcher would, in clang version 
without this patch here, fail to match if you had rewritten the `GetUri` method 
to use a qualified name? Something like this:

From:

  nsIPrincipal *getURI();

To:

  ::nsIPrincipal *getURI();

Ie qualify with the global namespace or something equivalent that works in the 
Firefox codebase?

I believe that matching to the canonical type would be the simplest fix for 
that bug:

On mozilla-central/build/clang-plugin/NoPrincipalGetURI.cpp change from:

  anyOf(on(hasType(asString("class nsIPrincipal *"))),
on(hasType(asString("class nsIPrincipal",

To:

  anyOf(on(hasType(hasCanonicalType(asString("class nsIPrincipal *",
on(hasType(hasCanonicalType(asString("class nsIPrincipal"),

Ie nest the `asString` matcher inside a `hasCanonicalType` matcher.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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

[Lldb-commits] [PATCH] D129682: [lldb] Filter DIEs based on qualified name when possible

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Well.. first of let me say that the performance gain is impressive. I wouldn't 
have expected to gain that much with a relatively simple change.

Now, as for the implementation, I have two main questions:

- Do we really need the `GetQualifiedNameWithParams` function? My impression 
was that we've been moving towards ignoring function arguments for name 
matching, and `CPlusPlusLanguage::DemangledNameContainsPath` does not look like 
it is making use of that. Note that I don't think that switching to 
`GetQualifiedName` is the right approach either. I think we should use the 
mangled name (`GetMangledName`) first, and only fall back to `GetQualifiedName` 
if that is unavailable (you can look up how it works during SymbolContext 
construction, but I believe it is roughly like that. (Incidentally, that will 
bring in the function arguments through the back door for some/most functions, 
but that isn't my motivation.)
- This patch is duplicating some of the logic inside 
`Module::LookupInfo::Prune`. I get that we can't reuse it as-is (because we'd 
need a `SymbolContext` object), but it seems like that function only cares 
about the `GetFunctionName` portion of the object, so it seems like it should 
be possible to refactor it such that one can reuse it from within this new 
context (just pass in a name instead of a full SymbolContext). (I guess this 
part could be a separate patch)




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:819-822
+  if (iterated) {
+storage.pop_back();
+storage.pop_back();
+  }

This is an interesting approach, but I'd just use llvm::ListSeparator for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129682

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

[Lldb-commits] [PATCH] D129724: [lldb] Remove ELF .zdebug support

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1610
 static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
   if (Name.consume_front(".debug_") || Name.consume_front(".zdebug_")) {
 return llvm::StringSwitch(Name)

I guess you can remove this as well now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129724

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

[Lldb-commits] [PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

[Sebastian Neubauer via Phabricator via lldb-commits]

sebastian-ne added a comment.

This breaks builds when LLVM is included with CMake’s `add_subdirectory`.
I think the zstd target needs to be marked as imported.
The following patch fixes the problem, although I’m not familiar enough with 
CMake to know if this is the right way to go:

  diff --git a/llvm/cmake/modules/FindZSTD.cmake 
b/llvm/cmake/modules/FindZSTD.cmake
  index 43ccf7232138..8e6ec6e8a988 100644
  --- a/llvm/cmake/modules/FindZSTD.cmake
  +++ b/llvm/cmake/modules/FindZSTD.cmake
  @@ -12,6 +12,10 @@ find_package_handle_standard_args(
   ZSTD_LIBRARY ZSTD_INCLUDE_DIR)
  
   if(ZSTD_FOUND)
  +if(NOT TARGET Zstd::zstd)
  +  add_library(Zstd::zstd UNKNOWN IMPORTED)
  +  set_target_properties(Zstd::zstd PROPERTIES IMPORTED_LOCATION 
"${ZSTD_LIBRARY}")
  +endif()
   set(ZSTD_LIBRARIES ${ZSTD_LIBRARY})
   set(ZSTD_INCLUDE_DIRS ${ZSTD_INCLUDE_DIR})
   endif()
  diff --git a/llvm/lib/Support/CMakeLists.txt b/llvm/lib/Support/CMakeLists.txt
  index 52b95c5377d3..031adfa33ba8 100644
  --- a/llvm/lib/Support/CMakeLists.txt
  +++ b/llvm/lib/Support/CMakeLists.txt
  @@ -26,7 +26,7 @@ if(LLVM_ENABLE_ZLIB)
   endif()
  
   if(LLVM_ENABLE_ZSTD)
  -  list(APPEND imported_libs zstd)
  +  list(APPEND imported_libs Zstd::zstd)
   endif()
  
   if( MSVC OR MINGW )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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

[Lldb-commits] [lldb] ac49e90 - jGetLoadedDynamicLibrariesInfos can inspect machos not yet loaded

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2022-07-14T00:56:14-07:00
New Revision: ac49e9021919d2a356dd10b39888f168736a43b0

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

LOG: jGetLoadedDynamicLibrariesInfos can inspect machos not yet loaded

jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld.  This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.

[This patch was reverted after causing a testsuite failure on a CI bot;
I haven't been able to repro the failure outside the CI, but I have a
theory that my sanity check on cputype which only matched arm64 and
x86_64 - and the CI machine may have a watch simulator that is still
using i386.]

Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734

Added: 
lldb/test/API/macosx/unregistered-macho/Makefile
lldb/test/API/macosx/unregistered-macho/TestUnregisteredMacho.py
lldb/test/API/macosx/unregistered-macho/main.c

Modified: 
lldb/tools/debugserver/source/MacOSX/MachProcess.h
lldb/tools/debugserver/source/MacOSX/MachProcess.mm

Removed: 




diff  --git a/lldb/test/API/macosx/unregistered-macho/Makefile 
b/lldb/test/API/macosx/unregistered-macho/Makefile
new file mode 100644
index 0..58c3a468659e3
--- /dev/null
+++ b/lldb/test/API/macosx/unregistered-macho/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES = main.c
+
+include Makefile.rules

diff  --git a/lldb/test/API/macosx/unregistered-macho/TestUnregisteredMacho.py 
b/lldb/test/API/macosx/unregistered-macho/TestUnregisteredMacho.py
new file mode 100644
index 0..0c3bb50aec89a
--- /dev/null
+++ b/lldb/test/API/macosx/unregistered-macho/TestUnregisteredMacho.py
@@ -0,0 +1,47 @@
+"""Test that debugserver will parse a mach-o in inferior memory even if it's 
not loaded."""
+
+import os
+import re
+import subprocess
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestUnregisteredMacho(TestBase):
+
+# newer debugserver required for jGetLoadedDynamicLibrariesInfos 
+# to support this
+@skipIfOutOfTreeDebugserver  
+@no_debug_info_test
+@skipUnlessDarwin
+def test(self):
+self.build()
+target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.c"))
+
+frame = thread.GetFrameAtIndex(0)
+macho_buf = frame.GetValueForVariablePath("macho_buf")
+macho_addr = macho_buf.GetValueAsUnsigned()
+invalid_macho_addr = macho_buf.GetValueAsUnsigned() + 4
+gdb_packet = "process plugin packet send 
'jGetLoadedDynamicLibrariesInfos:{\"solib_addresses\":[%d]}]'" % macho_addr
+
+# Send the jGetLoadedDynamicLibrariesInfos packet
+# to debugserver, asking it to parse the mach-o binary
+# at this address and give us the UUID etc, even though
+# dyld doesn't think there is a binary at that address.
+# We won't get a pathname for the binary (from dyld), but
+# we will get to the LC_UUID and include that.
+self.expect (gdb_packet, substrs=['"pathname":""', 
'"uuid":"1B4E28BA-2FA1-11D2-883F-B9A761BDE3FB"'])
+
+no_macho_gdb_packet = "process plugin packet send 
'jGetLoadedDynamicLibrariesInfos:{\"solib_addresses\":[%d]}]'" % 
invalid_macho_addr
+self.expect (no_macho_gdb_packet, substrs=['response: {"images":[]}'])
+
+# Test that we get back the information for the properly
+# formatted Mach-O binary in memory, but do not get an
+# entry for the invalid Mach-O address.
+both_gdb_packet = "process plugin packet send 
'jGetLoadedDynamicLibrariesInfos:{\"solib_addresses\":[%d,%d]}]'" % 
(macho_addr, invalid_macho_addr)
+self.expect (both_gdb_packet, substrs=['"load_address":%d,' % 
macho_addr])
+self.expect (both_gdb_packet, substrs=['"load_address":%d,' % 
invalid_macho_addr], matching=False)
+

diff  --git a/lldb/test/API/macosx/unregistered-macho/main.c 
b/lldb/test/API/macosx/unregistered-macho/main.c
new file mode 100644
index 0..5de4b5f642467
--- /dev/null
+++ b/lldb/test/API/macosx/unregistered-macho/main.c
@@ -0,0 +1,63 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main() {
+  int size_of_load_cmds =
+  sizeof(struct segment_command_64) + sizeof(struct 

[Lldb-commits] [PATCH] D129736: [lldb] Skip a float16 NaN test for RISC-V

[Emmmer S via Phabricator via lldb-commits]

Emmmer created this revision.
Emmmer added reviewers: MaskRay, liaolucy, craig.topper, DavidSpickett.
Emmmer added projects: LLDB, LLDB test suite on simulator.
Herald added subscribers: jsji, sunshaoce, VincentWu, luke957, StephenFan, 
vkmr, luismarques, sameer.abuasal, JDevlieghere, pengfei, s.egerton, Jim, PkmX, 
rogfer01, shiva0217, kito-cheng, simoncook, arichardson.
Herald added a project: All.
Emmmer requested review of this revision.
Herald added subscribers: lldb-commits, pcwang-thead.

When I try to run some unit tests, I met this problem

  [ RUN  ] DumpDataExtractorTest.Formats
  
/home/emmmer/git/llvm-project/lldb/unittests/Core/DumpDataExtractorTest.cpp:90: 
Failure
  Expected equality of these values:
expected
  Which is: "{-nan -nan nan nan}"
result.GetString()
  Which is: "{nan nan nan nan}"
  [  FAILED  ] DumpDataExtractorTest.Formats (25 ms)

So I extracted a minimal repro from `lldb/source/Core/DumpDataExtractor.cpp:53 
half2float(uint16_t half)` .

  #include 
  #include 
  #include 
  #include 
  
  int main() {
float f = 0;
*(uint32_t *)  = 0xe000;
float w = f * ldexpf(1, -112);
printf("%f(%x)\n", w, *(uint32_t *) );
return 0;
  }

On x86_64 it runs correctly.

  GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This GDB was configured as "x86_64-linux-gnu".
  Reading symbols from nan...
  (gdb) b main
  Breakpoint 1 at 0x113d: file nan.c, line 7.
  (gdb) r
  Starting program: /home/emmmer/nan
  
  Breakpoint 1, main () at nan.c:7
  7 float f = 0;
  (gdb) n
  8 *(uint32_t *)  = 0xe000;
  (gdb) n
  9 float w = f * ldexpf(1, -112);
  (gdb) n
  10printf("%f(%x)\n", w, *(uint32_t *) );
  (gdb) p w
  $1 = -nan(0x7fe000)  \\ -nan expected
  (gdb) p f
  $2 = -nan(0x7fe000)

But on riscv64, it seems to meet some problem.

  c
  GNU gdb (GDB) openEuler 11.1-2.oe2203
  Copyright (C) 2021 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  Reading symbols from nan...
  (gdb) b main
  Breakpoint 1 at 0x105e8: file nan.c, line 7.
  (gdb) r
  Starting program: /root/nan
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/usr/lib64/libthread_db.so.1".
  
  Breakpoint 1, main () at nan.c:7
  7 float f = 0;
  (gdb) n
  n8*(uint32_t *)  = 0xe000;
  (gdb) n
  9 float w = f * ldexpf(1, -112);
  (gdb) n
  10printf("%f(%x)\n", w, *(uint32_t *) );
  (gdb) p w
  $1 = nan(0x40)  \\ -nan expected
  (gdb) p f
  $2 = -nan(0x7fe000)

The problem occurs after line 9, the nan payload got lost after the float 
multiplication.

The problem only happens when running float16 tests, due to riscv standard does 
not enforce NaN payload propagation 
,
 so I would like to turn it off temporarily on the riscv platform, until more 
investigations are taken.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129736

Files:
  lldb/unittests/Core/DumpDataExtractorTest.cpp


Index: lldb/unittests/Core/DumpDataExtractorTest.cpp
===
--- lldb/unittests/Core/DumpDataExtractorTest.cpp
+++ lldb/unittests/Core/DumpDataExtractorTest.cpp
@@ -199,9 +199,11 @@
   TestDump(std::vector{0xabcd, 0x1234},
lldb::Format::eFormatVectorOfFloat16, "{-0.0609436 0.000757217}");
 
+#if !defined(__riscv)
   // quiet/signaling NaNs.
   TestDump(std::vector{0x, 0xffc0, 0x7fff, 0x7fc0},
lldb::Format::eFormatVectorOfFloat16, "{-nan -nan nan nan}");
+#endif
   // +/-Inf.
   TestDump(std::vector{0xfc00, 0x7c00},
lldb::Format::eFormatVectorOfFloat16, "{-inf inf}");


Index: lldb/unittests/Core/DumpDataExtractorTest.cpp
===
--- lldb/unittests/Core/DumpDataExtractorTest.cpp
+++ lldb/unittests/Core/DumpDataExtractorTest.cpp
@@ -199,9 +199,11 @@
   TestDump(std::vector{0xabcd, 0x1234},
lldb::Format::eFormatVectorOfFloat16, "{-0.0609436 0.000757217}");
 
+#if !defined(__riscv)
   // quiet/signaling NaNs.
   TestDump(std::vector{0x, 0xffc0, 0x7fff, 0x7fc0},
lldb::Format::eFormatVectorOfFloat16, "{-nan -nan nan nan}");
+#endif
   // +/-Inf.
   TestDump(std::vector{0xfc00, 0x7c00},
lldb::Format::eFormatVectorOfFloat16, "{-inf inf}");
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits