Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Galina Kistanova via lldb-commits]

Thanks, Vitaly!

Let's have them there for at least 24 hours, shall we?

Could you move sanitizer-buildbot1, sanitizer-buildbot3,
sanitizer-buildbot7 as well, please?

AnnotatedCommand on the staging has been tested functionally and is good.
My only concern at this point is how it would handle a heavy load, so the
more bots we will have on the staging the better.

If somebody else could move their AnnotatedCommand bots to the staging
area, that would be much appreciated.

Thanks

Galina

On Mon, Oct 12, 2020 at 9:45 PM Vitaly Buka  wrote:

> Looks like staging AnnotatedCommand fixed step statuses, so we can see
> which one is green.
> Please let me know when to switch bots back from the staging.
> Thank you!
>
> On Mon, 12 Oct 2020 at 21:38, Vitaly Buka  wrote:
>
>> Switched all but PPC, I don't have access to them. But they run the same
>> script as sanitizer-x86_64-linux.
>> http://lab.llvm.org:8014/#/waterfall?tags=sanitizer
>>
>> On Mon, 12 Oct 2020 at 19:19, Galina Kistanova 
>> wrote:
>>
>>> We have a better version of AnnotatedCommand on the staging. It should
>>> be a functional equivalent of the old one.
>>> We need to stress test it well before moving to the production build bot.
>>>
>>> For that we need all sanitizer + other bots which use the
>>> AnnotatedCommand directly or indirectly moved temporarily to the staging.
>>>
>>> Please let me know when that could be arranged.
>>>
>>> Thanks
>>>
>>> Galina
>>>
>>> On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner  wrote:
>>>
 On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> They are online now -
> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>
> AnnotatedCommand has severe design conflict with the new buildbot.
> We have changed it to be safe and still do something useful, but it
> will need more love and care.
>
> Please let me know if you have some spare time to work on porting
> AnnotatedCommand.
>

 That's unfortunate, it would've been good to know that earlier. I and
 another team member have spent a fair amount of time porting things to use
 more AnnotatedCommand steps, because it gives us the flexibility to test
 steps locally and make changes to the steps without restarting the buildbot
 master. IMO that is the Right Way to define steps: a script that you can
 run locally on a machine that satisfies the OS and dep requirements of the
 script.

 I am restarting the two bots that I am responsible for, and may need
 some help debugging further issues soon. I'll let you know.

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

[Lldb-commits] [PATCH] D89295: [lldb] Add /Users/jonas to Python's sys.path

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added reviewers: LLDB, labath, lawrence_danna.
JDevlieghere requested review of this revision.

Add support for importing scripts relative the current home directory.

rdar://68310384


https://reviews.llvm.org/D89295

Files:
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/test/Shell/ScriptInterpreter/Python/Inputs/zip.py
  lldb/test/Shell/ScriptInterpreter/Python/relative_import.test


Index: lldb/test/Shell/ScriptInterpreter/Python/relative_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/relative_import.test
@@ -0,0 +1,6 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: cp %S/Inputs/zip.py %t
+# RUN: env HOME=%t %lldb --script-language python -o 'command script import 
zip' -o 'zip' 2>&1 | FileCheck %s
+# CHECK: 95126
Index: lldb/test/Shell/ScriptInterpreter/Python/Inputs/zip.py
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/Inputs/zip.py
@@ -0,0 +1,7 @@
+import lldb
+
+def zip(debugger, command, result, internal_dict):
+print("95126")
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand('command script add -f zip.zip zip')
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -3229,11 +3229,16 @@
 
   LLDBSwigPyInit();
 
-  // Update the path python uses to search for modules to include the current
-  // directory.
-
+  // We need to call this before AddToSysPath as it uses the sys module.
   PyRun_SimpleString("import sys");
+
+  // Update the path python uses to search for modules to include the current
+  // directory and the home directory.
   AddToSysPath(AddLocation::End, ".");
+  FileSpec home_dir_spec;
+  llvm::SmallString<128> home_dir;
+  if (FileSystem::Instance().GetHomeDirectory(home_dir))
+AddToSysPath(AddLocation::End, std::string(home_dir));
 
   // Don't denormalize paths when calling file_spec.GetPath().  On platforms
   // that use a backslash as the path separator, this will result in executing


Index: lldb/test/Shell/ScriptInterpreter/Python/relative_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/relative_import.test
@@ -0,0 +1,6 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: cp %S/Inputs/zip.py %t
+# RUN: env HOME=%t %lldb --script-language python -o 'command script import zip' -o 'zip' 2>&1 | FileCheck %s
+# CHECK: 95126
Index: lldb/test/Shell/ScriptInterpreter/Python/Inputs/zip.py
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/Inputs/zip.py
@@ -0,0 +1,7 @@
+import lldb
+
+def zip(debugger, command, result, internal_dict):
+print("95126")
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand('command script add -f zip.zip zip')
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -3229,11 +3229,16 @@
 
   LLDBSwigPyInit();
 
-  // Update the path python uses to search for modules to include the current
-  // directory.
-
+  // We need to call this before AddToSysPath as it uses the sys module.
   PyRun_SimpleString("import sys");
+
+  // Update the path python uses to search for modules to include the current
+  // directory and the home directory.
   AddToSysPath(AddLocation::End, ".");
+  FileSpec home_dir_spec;
+  llvm::SmallString<128> home_dir;
+  if (FileSystem::Instance().GetHomeDirectory(home_dir))
+AddToSysPath(AddLocation::End, std::string(home_dir));
 
   // Don't denormalize paths when calling file_spec.GetPath().  On platforms
   // that use a backslash as the path separator, this will result in executing
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Vitaly Buka via lldb-commits]

Looks like staging AnnotatedCommand fixed step statuses, so we can see
which one is green.
Please let me know when to switch bots back from the staging.
Thank you!

On Mon, 12 Oct 2020 at 21:38, Vitaly Buka  wrote:

> Switched all but PPC, I don't have access to them. But they run the same
> script as sanitizer-x86_64-linux.
> http://lab.llvm.org:8014/#/waterfall?tags=sanitizer
>
> On Mon, 12 Oct 2020 at 19:19, Galina Kistanova 
> wrote:
>
>> We have a better version of AnnotatedCommand on the staging. It should be
>> a functional equivalent of the old one.
>> We need to stress test it well before moving to the production build bot.
>>
>> For that we need all sanitizer + other bots which use the
>> AnnotatedCommand directly or indirectly moved temporarily to the staging.
>>
>> Please let me know when that could be arranged.
>>
>> Thanks
>>
>> Galina
>>
>> On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner  wrote:
>>
>>> On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 They are online now -
 http://lab.llvm.org:8011/#/waterfall?tags=sanitizer

 AnnotatedCommand has severe design conflict with the new buildbot.
 We have changed it to be safe and still do something useful, but it
 will need more love and care.

 Please let me know if you have some spare time to work on porting
 AnnotatedCommand.

>>>
>>> That's unfortunate, it would've been good to know that earlier. I and
>>> another team member have spent a fair amount of time porting things to use
>>> more AnnotatedCommand steps, because it gives us the flexibility to test
>>> steps locally and make changes to the steps without restarting the buildbot
>>> master. IMO that is the Right Way to define steps: a script that you can
>>> run locally on a machine that satisfies the OS and dep requirements of the
>>> script.
>>>
>>> I am restarting the two bots that I am responsible for, and may need
>>> some help debugging further issues soon. I'll let you know.
>>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Vitaly Buka via lldb-commits]

Switched all but PPC, I don't have access to them. But they run the same
script as sanitizer-x86_64-linux.
http://lab.llvm.org:8014/#/waterfall?tags=sanitizer

On Mon, 12 Oct 2020 at 19:19, Galina Kistanova  wrote:

> We have a better version of AnnotatedCommand on the staging. It should be
> a functional equivalent of the old one.
> We need to stress test it well before moving to the production build bot.
>
> For that we need all sanitizer + other bots which use the AnnotatedCommand
> directly or indirectly moved temporarily to the staging.
>
> Please let me know when that could be arranged.
>
> Thanks
>
> Galina
>
> On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner  wrote:
>
>> On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> They are online now -
>>> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>>>
>>> AnnotatedCommand has severe design conflict with the new buildbot.
>>> We have changed it to be safe and still do something useful, but it will
>>> need more love and care.
>>>
>>> Please let me know if you have some spare time to work on porting
>>> AnnotatedCommand.
>>>
>>
>> That's unfortunate, it would've been good to know that earlier. I and
>> another team member have spent a fair amount of time porting things to use
>> more AnnotatedCommand steps, because it gives us the flexibility to test
>> steps locally and make changes to the steps without restarting the buildbot
>> master. IMO that is the Right Way to define steps: a script that you can
>> run locally on a machine that satisfies the OS and dep requirements of the
>> script.
>>
>> I am restarting the two bots that I am responsible for, and may need some
>> help debugging further issues soon. I'll let you know.
>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Galina Kistanova via lldb-commits]

We have a better version of AnnotatedCommand on the staging. It should be a
functional equivalent of the old one.
We need to stress test it well before moving to the production build bot.

For that we need all sanitizer + other bots which use the AnnotatedCommand
directly or indirectly moved temporarily to the staging.

Please let me know when that could be arranged.

Thanks

Galina

On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner  wrote:

> On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> They are online now - http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>>
>> AnnotatedCommand has severe design conflict with the new buildbot.
>> We have changed it to be safe and still do something useful, but it will
>> need more love and care.
>>
>> Please let me know if you have some spare time to work on porting
>> AnnotatedCommand.
>>
>
> That's unfortunate, it would've been good to know that earlier. I and
> another team member have spent a fair amount of time porting things to use
> more AnnotatedCommand steps, because it gives us the flexibility to test
> steps locally and make changes to the steps without restarting the buildbot
> master. IMO that is the Right Way to define steps: a script that you can
> run locally on a machine that satisfies the OS and dep requirements of the
> script.
>
> I am restarting the two bots that I am responsible for, and may need some
> help debugging further issues soon. I'll let you know.
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 297736.
wallace added a comment.

nits


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89283

Files:
  lldb/include/lldb/Target/Trace.h
  lldb/include/lldb/Target/TraceSessionFileParser.h
  lldb/include/lldb/Target/TraceThread.h
  lldb/include/lldb/lldb-forward.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.cpp
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.h
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
  lldb/source/Target/CMakeLists.txt
  lldb/source/Target/Thread.cpp
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSessionFileParser.cpp
  lldb/source/Target/TraceThread.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
  lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 2123123,
+  "model": 12123123,
+  "stepping": 1231231
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x00F0",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/TestTraceDumpInstructions.py
===
--- lldb/test/API/commands/trace/TestTraceDumpInstructions.py
+++ lldb/test/API/commands/trace/TestTraceDumpInstructions.py
@@ -39,18 +39,41 @@
 substrs=["intel-pt"])
 
 self.expect("thread trace dump instructions",
-substrs=['thread #1: tid = 3842849, total instructions = 1000',
- 'would print 20 instructions from position 0'])
+substrs=['''thread #1: tid = 3842849, total instructions = 22
+  [ 0] 0x40052d
+  [ 1] 0x40052d
+  [ 2] 0x400529
+  [ 3] 0x400525
+  [ 4] 0x400521
+  [ 5] 0x40052d
+  [ 6] 0x400529
+  [ 7] 0x400525
+  [ 8] 0x400521
+  [ 9] 0x40052d
+  [10] 0x400529
+  [11] 0x400525
+  [12] 0x400521
+  [13] 0x40052d
+  [14] 0x400529
+  [15] 0x400525
+  [16] 0x400521
+  [17] 0x40052d
+  [18] 0x400529
+  [19] 0x40051f'''])
 
 # We check if we can pass count and offset
 self.expect("thread trace dump instructions --count 5 --start-position 10",
-substrs=['thread #1: tid = 3842849, total instructions = 1000',
- 'would print 5 instructions from position 10'])
+substrs=['''thread #1: tid = 3842849, total instructions = 22
+  [10] 0x400529
+  [11] 0x400525
+  [12] 0x400521
+  [13] 0x40052d
+  [14] 0x400529'''])
 
 # We check if we can access the thread by index id
 self.expect("thread trace dump instructions 1",
-substrs=['thread #1: tid = 3842849, total instructions = 1000',
- 'would print 20 instructions from position 0'])
+substrs=['''thread #1: tid = 3842849, total instructions = 22
+  [ 0] 0x40052d'''])
 
 # We check that we get an error when using an invalid thread index id
 self.expect("thread trace dump instructions 10", error=True,
@@ -61,32 

[Lldb-commits] [lldb] ec2c2ad - Add accessors. (NFC)

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2020-10-12T17:45:49-07:00
New Revision: ec2c2ad2a2dddf24b052625b5ff434704ea43e24

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

LOG: Add accessors. (NFC)

There's a place in swift-lldb where it is useful to create a copy of
an lldb_private::Variable. Adding these two accessors makes this
possible.

Added: 


Modified: 
lldb/include/lldb/Symbol/Type.h
lldb/include/lldb/Symbol/Variable.h

Removed: 




diff  --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index efd3ede03445..06fc1d5da0aa 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -56,6 +56,7 @@ class SymbolFileType : public 
std::enable_shared_from_this,
   Type *operator->() { return GetType(); }
 
   Type *GetType();
+  SymbolFile () const { return m_symbol_file; }
 
 protected:
   SymbolFile _symbol_file;

diff  --git a/lldb/include/lldb/Symbol/Variable.h 
b/lldb/include/lldb/Symbol/Variable.h
index 66abdc0b3117..37bd9ca68533 100644
--- a/lldb/include/lldb/Symbol/Variable.h
+++ b/lldb/include/lldb/Symbol/Variable.h
@@ -64,6 +64,8 @@ class Variable : public UserID, public 
std::enable_shared_from_this {
 
   lldb::ValueType GetScope() const { return m_scope; }
 
+  const RangeList () const { return m_scope_range; }
+
   bool IsExternal() const { return m_external; }
 
   bool IsArtificial() const { return m_artificial; }



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

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

[walter erquinigo via Phabricator via lldb-commits]

wallace created this revision.
Herald added subscribers: lldb-commits, mgorny.
Herald added a reviewer: JDevlieghere.
Herald added a project: LLDB.
wallace requested review of this revision.

This diff finally implements trace decoding!

The current interface is

  $ trace load /path/to/trace/session/file.json
  $ thread trace dump instructions
  
  thread #1: tid = 3842849, total instructions = 22
[ 0] 0x40052d
[ 1] 0x40052d  
...
[19] 0x400521
  
  $ # simply enter, which is a repeat command
[20] 0x40052d
[21] 0x400529
...

This doesn't do any disassembly, which will be done in the next diff.

Changes:

- Renamed ThreadIntelPT to TreaceThread, which is a top-level class. I noticed 
that this should work for any trace plugin and there's nothing intel-pt 
specific to it.
- With that ThreadThread change, I was able to move most of the json file 
parsing logic to the base class TraceSessionFileParser, which makes adding new 
plug-ins easier.
- Added an IntelPTDecoder class, which is a wrapper for libipt, which is the 
actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes TraceThreads and memoizes the 
result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and 
that for the time being only stored the list of reconstructed instructions. 
Later it'll contain the function call hierarchy, which will enable 
reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
  - GetInstructionCount, which counts the number of instructions traced for a 
given thread
  - IsTraceFailed, which returns an Error if decoding a thread failed
  - ForEachInstruction, which iterates on the instructions traced for a given 
thread, concealing the internal storage of threads, as plug-ins can decide to 
generate the instructions on the fly or to store them all in a vector, like I 
do.
- DumpTraceInstructions was updated to print the instructions or show an error 
message if decoding was impossible.
- Tests included


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89283

Files:
  lldb/include/lldb/Target/Trace.h
  lldb/include/lldb/Target/TraceSessionFileParser.h
  lldb/include/lldb/Target/TraceThread.h
  lldb/include/lldb/lldb-forward.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.cpp
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.h
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
  lldb/source/Target/CMakeLists.txt
  lldb/source/Target/Thread.cpp
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSessionFileParser.cpp
  lldb/source/Target/TraceThread.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
  lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 2123123,
+  "model": 12123123,
+  "stepping": 1231231
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x00F0",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}

[Lldb-commits] [PATCH] D88939: [lldb] Remove unused code in GetVersion (NFC)

[Dave Lee via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG08924b54debc: [lldb] Remove unused code in GetVersion (NFC) 
(authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88939

Files:
  lldb/source/lldb.cpp


Index: lldb/source/lldb.cpp
===
--- lldb/source/lldb.cpp
+++ lldb/source/lldb.cpp
@@ -33,12 +33,7 @@
 #endif
 }
 
-#define QUOTE(str) #str
-#define EXPAND_AND_QUOTE(str) QUOTE(str)
-
 const char *lldb_private::GetVersion() {
-  // On platforms other than Darwin, report a version number in the same style
-  // as the clang tool.
   static std::string g_version_str;
   if (g_version_str.empty()) {
 g_version_str += "lldb version ";


Index: lldb/source/lldb.cpp
===
--- lldb/source/lldb.cpp
+++ lldb/source/lldb.cpp
@@ -33,12 +33,7 @@
 #endif
 }
 
-#define QUOTE(str) #str
-#define EXPAND_AND_QUOTE(str) QUOTE(str)
-
 const char *lldb_private::GetVersion() {
-  // On platforms other than Darwin, report a version number in the same style
-  // as the clang tool.
   static std::string g_version_str;
   if (g_version_str.empty()) {
 g_version_str += "lldb version ";
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 08924b5 - [lldb] Remove unused code in GetVersion (NFC)

[Dave Lee via lldb-commits]

Author: Dave Lee
Date: 2020-10-12T16:31:14-07:00
New Revision: 08924b54debcfd47bcf22a8213308cec7d22b975

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

LOG: [lldb] Remove unused code in GetVersion (NFC)

Small cleanup to `lldb_private::GetVersion()`.

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

Added: 


Modified: 
lldb/source/lldb.cpp

Removed: 




diff  --git a/lldb/source/lldb.cpp b/lldb/source/lldb.cpp
index 6d4ed66074dc..4d4c636a4f9c 100644
--- a/lldb/source/lldb.cpp
+++ b/lldb/source/lldb.cpp
@@ -33,12 +33,7 @@ static const char *GetLLDBRepository() {
 #endif
 }
 
-#define QUOTE(str) #str
-#define EXPAND_AND_QUOTE(str) QUOTE(str)
-
 const char *lldb_private::GetVersion() {
-  // On platforms other than Darwin, report a version number in the same style
-  // as the clang tool.
   static std::string g_version_str;
   if (g_version_str.empty()) {
 g_version_str += "lldb version ";



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

[Lldb-commits] [PATCH] D89273: [lldb] Handle alternative output in TestAbortExitCode

[Dave Lee via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa52cc9b4be36: [lldb] Handle alternative output in 
TestAbortExitCode (authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89273

Files:
  lldb/test/Shell/Process/TestAbortExitCode.test


Index: lldb/test/Shell/Process/TestAbortExitCode.test
===
--- lldb/test/Shell/Process/TestAbortExitCode.test
+++ lldb/test/Shell/Process/TestAbortExitCode.test
@@ -3,4 +3,4 @@
 RUN: %clang_host %p/Inputs/abort.c -o %t
 RUN: %lldb %t -o run -o continue | FileCheck %s
 
-CHECK: status = 6 (0x0006)
+CHECK: {{status = 6 \(0x0006\)|status = 0 \(0x\) Terminated due to 
signal 6}}


Index: lldb/test/Shell/Process/TestAbortExitCode.test
===
--- lldb/test/Shell/Process/TestAbortExitCode.test
+++ lldb/test/Shell/Process/TestAbortExitCode.test
@@ -3,4 +3,4 @@
 RUN: %clang_host %p/Inputs/abort.c -o %t
 RUN: %lldb %t -o run -o continue | FileCheck %s
 
-CHECK: status = 6 (0x0006)
+CHECK: {{status = 6 \(0x0006\)|status = 0 \(0x\) Terminated due to signal 6}}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] a52cc9b - [lldb] Handle alternative output in TestAbortExitCode

[Dave Lee via lldb-commits]

Author: Dave Lee
Date: 2020-10-12T16:27:06-07:00
New Revision: a52cc9b4be362b12ca261000b723374d4b772a45

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

LOG: [lldb] Handle alternative output in TestAbortExitCode

This test

On macOS, this test can instead return `status = 0 (0x) Terminated due 
to signal 6`. This updates the `CHECK` accordingly.

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

Added: 


Modified: 
lldb/test/Shell/Process/TestAbortExitCode.test

Removed: 




diff  --git a/lldb/test/Shell/Process/TestAbortExitCode.test 
b/lldb/test/Shell/Process/TestAbortExitCode.test
index 5be0a15ab172..746bc915897e 100644
--- a/lldb/test/Shell/Process/TestAbortExitCode.test
+++ b/lldb/test/Shell/Process/TestAbortExitCode.test
@@ -3,4 +3,4 @@ UNSUPPORTED: system-windows
 RUN: %clang_host %p/Inputs/abort.c -o %t
 RUN: %lldb %t -o run -o continue | FileCheck %s
 
-CHECK: status = 6 (0x0006)
+CHECK: {{status = 6 \(0x0006\)|status = 0 \(0x\) Terminated due to 
signal 6}}



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

[Lldb-commits] [lldb] 360ab00 - [lldb] Add instrumentation runtime category

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-10-12T16:02:40-07:00
New Revision: 360ab009e2b95629388cef132ebe639c120ed35e

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

LOG: [lldb] Add instrumentation runtime category

Added: 
lldb/test/API/functionalities/asan/.categories
lldb/test/API/functionalities/mtc/.categories
lldb/test/API/functionalities/tsan/.categories
lldb/test/API/functionalities/ubsan/.categories

Modified: 
lldb/packages/Python/lldbsuite/test/test_categories.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/test_categories.py 
b/lldb/packages/Python/lldbsuite/test/test_categories.py
index dcfef5be04ac..699fcf4cb887 100644
--- a/lldb/packages/Python/lldbsuite/test/test_categories.py
+++ b/lldb/packages/Python/lldbsuite/test/test_categories.py
@@ -30,6 +30,7 @@
 'expression': 'Tests related to the expression parser',
 'flakey': 'Flakey test cases, i.e. tests that do not reliably pass at each 
execution',
 'gmodules': 'Tests that can be run with -gmodules debug information',
+'instrumentation-runtime': 'Tests for the instrumentation runtime plugins',
 'libc++': 'Test for libc++ data formatters',
 'libstdcxx': 'Test for libstdcxx data formatters',
 'lldb-server': 'Tests related to lldb-server',

diff  --git a/lldb/test/API/functionalities/asan/.categories 
b/lldb/test/API/functionalities/asan/.categories
new file mode 100644
index ..c756cb124194
--- /dev/null
+++ b/lldb/test/API/functionalities/asan/.categories
@@ -0,0 +1 @@
+instrumentation-runtime

diff  --git a/lldb/test/API/functionalities/mtc/.categories 
b/lldb/test/API/functionalities/mtc/.categories
new file mode 100644
index ..c756cb124194
--- /dev/null
+++ b/lldb/test/API/functionalities/mtc/.categories
@@ -0,0 +1 @@
+instrumentation-runtime

diff  --git a/lldb/test/API/functionalities/tsan/.categories 
b/lldb/test/API/functionalities/tsan/.categories
new file mode 100644
index ..c756cb124194
--- /dev/null
+++ b/lldb/test/API/functionalities/tsan/.categories
@@ -0,0 +1 @@
+instrumentation-runtime

diff  --git a/lldb/test/API/functionalities/ubsan/.categories 
b/lldb/test/API/functionalities/ubsan/.categories
new file mode 100644
index ..c756cb124194
--- /dev/null
+++ b/lldb/test/API/functionalities/ubsan/.categories
@@ -0,0 +1 @@
+instrumentation-runtime



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

[Lldb-commits] [lldb] e465dda - [lldb] Alphabetically sort test categories (NFC)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-10-12T16:02:40-07:00
New Revision: e465ddac880228b879b5a6549adbb9c8a7f335bf

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

LOG: [lldb] Alphabetically sort test categories (NFC)

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/test_categories.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/test_categories.py 
b/lldb/packages/Python/lldbsuite/test/test_categories.py
index 177c50ee17cf..dcfef5be04ac 100644
--- a/lldb/packages/Python/lldbsuite/test/test_categories.py
+++ b/lldb/packages/Python/lldbsuite/test/test_categories.py
@@ -19,26 +19,26 @@
 ]
 
 all_categories = {
+'basic_process': 'Basic process execution sniff tests.',
+'cmdline': 'Tests related to the LLDB command-line interface',
+'darwin-log': 'Darwin log tests',
 'dataformatters': 'Tests related to the type command and the data 
formatters subsystem',
+'dsym': 'Tests that can be run with DSYM debug information',
 'dwarf': 'Tests that can be run with DWARF debug information',
 'dwo': 'Tests that can be run with DWO debug information',
-'dsym': 'Tests that can be run with DSYM debug information',
-'gmodules': 'Tests that can be run with -gmodules debug information',
+'dyntype': 'Tests related to dynamic type support',
 'expression': 'Tests related to the expression parser',
+'flakey': 'Flakey test cases, i.e. tests that do not reliably pass at each 
execution',
+'gmodules': 'Tests that can be run with -gmodules debug information',
 'libc++': 'Test for libc++ data formatters',
 'libstdcxx': 'Test for libstdcxx data formatters',
+'lldb-server': 'Tests related to lldb-server',
+'lldb-vscode': 'Visual Studio Code debug adaptor tests',
 'objc': 'Tests related to the Objective-C programming language support',
 'pyapi': 'Tests related to the Python API',
-'basic_process': 'Basic process execution sniff tests.',
-'cmdline': 'Tests related to the LLDB command-line interface',
-'dyntype': 'Tests related to dynamic type support',
-'stresstest': 'Tests related to stressing lldb limits',
-'flakey': 'Flakey test cases, i.e. tests that do not reliably pass at each 
execution',
-'darwin-log': 'Darwin log tests',
 'std-module': 'Tests related to importing the std module',
+'stresstest': 'Tests related to stressing lldb limits',
 'watchpoint': 'Watchpoint-related tests',
-'lldb-vscode': 'Visual Studio Code debug adaptor tests',
-'lldb-server': 'Tests related to lldb-server',
 }
 
 



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

[Lldb-commits] [PATCH] D89273: [lldb] Handle alternative output in TestAbortExitCode

[Dave Lee via Phabricator via lldb-commits]

kastiglione created this revision.
kastiglione added reviewers: aprantl, JDevlieghere.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
kastiglione requested review of this revision.

This test

On macOS, this test can instead return `status = 0 (0x) Terminated due 
to signal 6`. This updates the `CHECK` accordingly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89273

Files:
  lldb/test/Shell/Process/TestAbortExitCode.test


Index: lldb/test/Shell/Process/TestAbortExitCode.test
===
--- lldb/test/Shell/Process/TestAbortExitCode.test
+++ lldb/test/Shell/Process/TestAbortExitCode.test
@@ -3,4 +3,4 @@
 RUN: %clang_host %p/Inputs/abort.c -o %t
 RUN: %lldb %t -o run -o continue | FileCheck %s
 
-CHECK: status = 6 (0x0006)
+CHECK: {{status = 6 \(0x0006\)|status = 0 \(0x\) Terminated due to 
signal 6}}


Index: lldb/test/Shell/Process/TestAbortExitCode.test
===
--- lldb/test/Shell/Process/TestAbortExitCode.test
+++ lldb/test/Shell/Process/TestAbortExitCode.test
@@ -3,4 +3,4 @@
 RUN: %clang_host %p/Inputs/abort.c -o %t
 RUN: %lldb %t -o run -o continue | FileCheck %s
 
-CHECK: status = 6 (0x0006)
+CHECK: {{status = 6 \(0x0006\)|status = 0 \(0x\) Terminated due to signal 6}}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89124: [lldb-server][linux] Add ability to allocate memory

[Jan Kratochvil via Phabricator via lldb-commits]

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



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1362
+
+  NativeThreadLinux  = *GetThreadByID(GetID());
+  assert(thread.GetState() == eStateStopped);

There does not need to exist a thread with TID equal to the process PID. That 
TID could already exit while other TIDs of that PID may be still running.
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=432b4d03ad0f23970315e9f9dec080ab4a9ab94b
simplified and deGPLed as: https://people.redhat.com/jkratoch/leader-exit2.C
Just currently LLDB server cannot attach to such TID as:
  lldb-server g --attach >TID< :1234
  ptrace(PTRACE_ATTACH, >PID<) = -1 EPERM (Operation not permitted)
  write(2, "error: failed to attach to pid >TID<: Operation not permitted\n", 
64) = 64
But if this bug was fixed then I think this statement could SEGV (unless LLDB 
will have some internal zombie TID==PID).




Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp:1237
+  lldb_rdx_x86_64, lldb_r10_x86_64, lldb_r8_x86_64,
+  lldb_r9_x86_64};
+return SyscallData{Syscall, Args, lldb_rax_x86_64};

static const ... (4x)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89124

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

[Lldb-commits] [lldb] 26d861c - [trace] Scaffold "thread trace dump instructions"

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2020-10-12T12:08:18-07:00
New Revision: 26d861cbbd5f40182b3b7f0ac7ed0e58e0e8feaa

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

LOG: [trace] Scaffold "thread trace dump instructions"

Depends on D88841

As per the discussion in the RFC, we'll implement both

  thread trace dump [instructions | functions]

This is the first step in implementing the "instructions" dumping command.

It includes:

- A minimal ProcessTrace plugin for representing processes from a trace file. I 
noticed that it was a required step to mimic how core-based processes are 
initialized, e.g. ProcessElfCore and ProcessMinidump. I haven't had the need to 
create ThreadTrace yet, though. So far HistoryThread seems good enough.
- The command handling itself in CommandObjectThread, which outputs a 
placeholder text instead of the actual instructions. I'll do that part in the 
next diff.
- Tests

{F13132325}

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

Added: 
lldb/source/Plugins/Process/Trace/CMakeLists.txt
lldb/source/Plugins/Process/Trace/ProcessTrace.cpp
lldb/source/Plugins/Process/Trace/ProcessTrace.h
lldb/test/API/commands/trace/TestTraceDumpInstructions.py
lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json

Modified: 
lldb/include/lldb/Target/Target.h
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/Target/Trace.h
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Commands/Options.td
lldb/source/Plugins/Process/CMakeLists.txt
lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
lldb/source/Target/Target.cpp
lldb/source/Target/Trace.cpp
lldb/test/API/commands/trace/TestTraceLoad.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 7ee27a9776d5c..f371c4fd69565 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1105,6 +1105,20 @@ class Target : public 
std::enable_shared_from_this,
 
   void ClearAllLoadedSections();
 
+  /// Set the \a Trace object containing processor trace information of this
+  /// target.
+  ///
+  /// \param[in] trace_sp
+  ///   The trace object.
+  void SetTrace(const lldb::TraceSP _sp);
+
+  /// Get the \a Trace object containing processor trace information of this
+  /// target.
+  ///
+  /// \return
+  ///   The trace object. It might be undefined.
+  const lldb::TraceSP ();
+
   // Since expressions results can persist beyond the lifetime of a process,
   // and the const expression results are available after a process is gone, we
   // provide a way for expressions to be evaluated from the Target itself. If
@@ -1402,6 +1416,9 @@ class Target : public 
std::enable_shared_from_this,
   bool m_suppress_stop_hooks;
   bool m_is_dummy_target;
   unsigned m_next_persistent_variable_index = 0;
+  /// An optional \a lldb_private::Trace object containing processor trace
+  /// information of this target.
+  lldb::TraceSP m_trace_sp;
   /// Stores the frame recognizers of this target.
   lldb::StackFrameRecognizerManagerUP m_frame_recognizer_manager_up;
 

diff  --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index 59e4d8a8f8727..4b148063ec6ee 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -469,6 +469,24 @@ class Thread : public std::enable_shared_from_this,
 // the backing thread for all memory threads each time we stop.
   }
 
+  /// Dump \a count instructions of the thread's \a Trace starting at the \a
+  /// start_position position in reverse order.
+  ///
+  /// The instructions are indexed in reverse order, which means that the \a
+  /// start_position 0 represents the last instruction of the trace
+  /// chronologically.
+  ///
+  /// \param[in] s
+  ///   The stream object where the instructions are printed.
+  ///
+  /// \param[in] count
+  /// The number of instructions to print.
+  ///
+  /// \param[in] start_position
+  /// The position of the first instruction to print.
+  void DumpTraceInstructions(Stream , size_t count,
+ size_t start_position = 0) const;
+
   // If stop_format is true, this will be the form used when we print stop
   // info. If false, it will be the form we use for thread list and co.
   void DumpUsingSettingsFormat(Stream , uint32_t frame_idx,

diff  --git a/lldb/include/lldb/Target/Trace.h 
b/lldb/include/lldb/Target/Trace.h
index 09d18525a5583..7ecab7262cbf0 100644
--- a/lldb/include/lldb/Target/Trace.h
+++ b/lldb/include/lldb/Target/Trace.h
@@ -32,7 +32,8 @@ namespace lldb_private {
 /// Processor 

[Lldb-commits] [PATCH] D88769: [trace] Scaffold "thread trace dump instructions"

[Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG26d861cbbd5f: [trace] Scaffold thread trace dump 
instructions (authored by Walter Erquinigo wall...@fb.com).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88769

Files:
  lldb/include/lldb/Target/Target.h
  lldb/include/lldb/Target/Thread.h
  lldb/include/lldb/Target/Trace.h
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/Trace/CMakeLists.txt
  lldb/source/Plugins/Process/Trace/ProcessTrace.cpp
  lldb/source/Plugins/Process/Trace/ProcessTrace.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Target/Target.cpp
  lldb/source/Target/Trace.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json
@@ -0,0 +1,35 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+},
+{
+  "tid": 3842850,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/TestTraceLoad.py
===
--- lldb/test/API/commands/trace/TestTraceLoad.py
+++ lldb/test/API/commands/trace/TestTraceLoad.py
@@ -35,6 +35,10 @@
 
 self.assertEqual("6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A", module.GetUUIDString())
 
+# check that the Process and Thread objects were created correctly
+self.expect("thread info", substrs=["tid = 3842849"])
+self.expect("thread list", substrs=["Process 1234 stopped", "tid = 3842849"])
+
 
 def testLoadInvalidTraces(self):
 src_dir = self.getSourceDir()
Index: lldb/test/API/commands/trace/TestTraceDumpInstructions.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceDumpInstructions.py
@@ -0,0 +1,92 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceDumpInstructions(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+TestBase.setUp(self)
+if 'intel-pt' not in configuration.enabled_plugins:
+self.skipTest("The intel-pt test plugin is not enabled")
+
+def testErrorMessages(self):
+# We first check the output when there are no targets
+self.expect("thread trace dump instructions",
+substrs=["error: invalid target, create a target using the 'target create' command"],
+error=True)
+
+# We now check the output when there's a non-running target
+self.expect("target create " + os.path.join(self.getSourceDir(), "intelpt-trace", "a.out"))
+
+self.expect("thread trace dump instructions",
+substrs=["error: invalid process"],
+error=True)
+
+# Now we check the output when there's a running target without a trace
+self.expect("b main")
+self.expect("run")
+
+self.expect("thread trace dump instructions",
+substrs=["error: this thread is not being traced"],
+error=True)
+
+def testDumpInstructions(self):
+self.expect("trace load -v " + os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"),
+substrs=["intel-pt"])
+
+self.expect("thread trace dump instructions",
+substrs=['thread #1: tid = 3842849, total instructions = 1000',
+ 'would print 20 instructions from position 0'])
+
+# We check if we can pass count and offset
+self.expect("thread trace dump instructions --count 5 --start-position 10",
+substrs=['thread #1: tid = 3842849, total instructions = 1000',
+ 'would print 5 instructions from position 10'])
+
+  

Re: [Lldb-commits] [llvm-dev] [cfe-dev] Upcoming upgrade of LLVM buildbot

[Andrzej Warzynski via lldb-commits]

I switched one of our workers to the main Buildbot and everything seems 
fine #fingers-crossed. I guess that that was a temporary glitch?


We haven't updated our local Buildbot installations - still on 0.8.5. 
Should we update?


-Andrzej

On 09/10/2020 00:44, Galina Kistanova wrote:

Hi Paula,

This error is fine. The buildbot has tested the worker version. 0.8.x 
apparently does not have that method.
The error gets handled gracefully on the server side. At least it seems 
so so far.


That should not prevent your bot from connecting.

Thanks

Galina

On Thu, Oct 8, 2020 at 2:11 PM Paula Askar > wrote:


Hey Andrzej,

What are you seeing in your buildbot logs? Is it this error?
`twisted.spread.flavors.NoSuchMethod: No such method:
remote_getWorkerInfo`

If so, you might want to try updating your buildbot worker.
I updated llvmlibc's to 2.8.4 and that seemed to solve the connection
problem:

https://github.com/llvm/llvm-project/commit/f60686f35cc89504f3411f49cf16a651a74be6eb

Best,
Paula Askar


On Thu, Oct 8, 2020 at 5:43 AM Andrzej Warzynski via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
 >
 > Our Flang-aarch64 buildbots just won't connect to the main Buildbot
 > master anymore. I switched them to the staging buildbot master
instead
 > and it seems fine for now. Is there anything that we can/should
tweak at
 > our end?
 >
 > http://lab.llvm.org:8014/#/waterfall?tags=flang
 >
 > -Andrzej
 >
 > On 08/10/2020 00:31, Galina Kistanova via cfe-dev wrote:
 > > They are online now -
http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
 > >
 > > AnnotatedCommand has severe design conflict with the new buildbot.
 > > We have changed it to be safe and still do something useful,
but it will
 > > need more love and care.
 > >
 > > Please let me know if you have some spare time to work on porting
 > > AnnotatedCommand.
 > >
 > > Thanks
 > >
 > > Galina
 > >
 > > On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka
mailto:vitalyb...@google.com>
 > > >>
wrote:
 > >
 > >     It looks like all sanitizer builder are still offline
 > > http://lab.llvm.org:8011/#/builders
 > >
 > >     On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits
 > >     mailto:cfe-comm...@lists.llvm.org>
>> wrote:
 > >
 > >         Hello everyone,
 > >
 > >         The staging buildbot was up and running for 6 days now, and
 > >         looks good.
 > >
 > >         Tomorrow at 12:00 PM PDT we will switch the production
buildbot
 > >         to the new version.
 > >
 > >         If you are a bot owner, you do not need to do anything
at this
 > >         point, unless I'll ask you to help.
 > >         The buildbot will go down for a short period of time,
and then a
 > >         new version will come up and will accept connections
from your bots.
 > >
 > >         Please note that the new version has a bit different URL
 > >         structure. You will need to update the bookmarks or
scripts if
 > >         you have stored direct URLs to inside the buldbot.
 > >
 > >         We will be watching the production and staging bots and
will be
 > >         improving zorg for the next week or so.
 > >
 > >         I will need your feedback about blame e-mails delivery, IRC
 > >         reporting issues, and anything you could spot wrong
with the new
 > >         bot. I  hope the transition will go smoothly and we
will handle
 > >         issues quickly if any would come up.
 > >
 > >         After production is good and we have about a week of
running
 > >         history, I'll ask the bot owners to upgrade buildbots
on their
 > >         side. Please do not upgrade your buildbots unless I'll
ask you
 > >         to. We are trying to limit a number of moving parts at this
 > >         stage. We will start accepting change to zorg at this
point.
 > >         Please feel free to talk to me if you will have a special
 > >         situation and if you would absolutely have to make changes.
 > >
 > >         Thanks for your support and help. And please feel free
to ask if
 > >         you have questions.
 > >
 > >         Galina
 > >
 > >
 > >         On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova
 > >         mailto:gkistan...@gmail.com>
>> wrote:
 > >
 > >             Hello everyone,
 > >
 > >             The buildbot upgrade is entering the phase when the
results
 > >             to become 

Re: [Lldb-commits] [llvm-dev] [cfe-dev] Upcoming upgrade of LLVM buildbot

[Paula Askar via lldb-commits]

Hey Andrzej,

What are you seeing in your buildbot logs? Is it this error?
`twisted.spread.flavors.NoSuchMethod: No such method:
remote_getWorkerInfo`

If so, you might want to try updating your buildbot worker.
I updated llvmlibc's to 2.8.4 and that seemed to solve the connection
problem: 
https://github.com/llvm/llvm-project/commit/f60686f35cc89504f3411f49cf16a651a74be6eb

Best,
Paula Askar


On Thu, Oct 8, 2020 at 5:43 AM Andrzej Warzynski via llvm-dev
 wrote:
>
> Our Flang-aarch64 buildbots just won't connect to the main Buildbot
> master anymore. I switched them to the staging buildbot master instead
> and it seems fine for now. Is there anything that we can/should tweak at
> our end?
>
> http://lab.llvm.org:8014/#/waterfall?tags=flang
>
> -Andrzej
>
> On 08/10/2020 00:31, Galina Kistanova via cfe-dev wrote:
> > They are online now - http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
> >
> > AnnotatedCommand has severe design conflict with the new buildbot.
> > We have changed it to be safe and still do something useful, but it will
> > need more love and care.
> >
> > Please let me know if you have some spare time to work on porting
> > AnnotatedCommand.
> >
> > Thanks
> >
> > Galina
> >
> > On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka  > > wrote:
> >
> > It looks like all sanitizer builder are still offline
> > http://lab.llvm.org:8011/#/builders
> >
> > On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits
> > mailto:cfe-comm...@lists.llvm.org>> wrote:
> >
> > Hello everyone,
> >
> > The staging buildbot was up and running for 6 days now, and
> > looks good.
> >
> > Tomorrow at 12:00 PM PDT we will switch the production buildbot
> > to the new version.
> >
> > If you are a bot owner, you do not need to do anything at this
> > point, unless I'll ask you to help.
> > The buildbot will go down for a short period of time, and then a
> > new version will come up and will accept connections from your bots.
> >
> > Please note that the new version has a bit different URL
> > structure. You will need to update the bookmarks or scripts if
> > you have stored direct URLs to inside the buldbot.
> >
> > We will be watching the production and staging bots and will be
> > improving zorg for the next week or so.
> >
> > I will need your feedback about blame e-mails delivery, IRC
> > reporting issues, and anything you could spot wrong with the new
> > bot. I  hope the transition will go smoothly and we will handle
> > issues quickly if any would come up.
> >
> > After production is good and we have about a week of running
> > history, I'll ask the bot owners to upgrade buildbots on their
> > side. Please do not upgrade your buildbots unless I'll ask you
> > to. We are trying to limit a number of moving parts at this
> > stage. We will start accepting change to zorg at this point.
> > Please feel free to talk to me if you will have a special
> > situation and if you would absolutely have to make changes.
> >
> > Thanks for your support and help. And please feel free to ask if
> > you have questions.
> >
> > Galina
> >
> >
> > On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova
> > mailto:gkistan...@gmail.com>> wrote:
> >
> > Hello everyone,
> >
> > The buildbot upgrade is entering the phase when the results
> > to become visible.
> >
> > No change is required at this time on any of the builders.
> > The bot owners could upgrade the buildbot on build computers
> > later, at their convenience, as this is not on the critical
> > path.
> >
> > We are going to upgrade the staging bot first. Then, once
> > that is stable and all detected issues are resolved, we will
> > upgrade the production bot.
> >
> > I will need some help with testing, and will be asking to
> > move some of the builders temporarily to the staging. LLVM
> > buildbot is a piece of critical infrastructure, so more eyes
> > and hands in making sure it works properly the better.
> >
> > I'll be posting updates and ETA of particular changes in
> > this thread.
> >
> > Please feel free to ask if you have any questions or concerns.
> >
> > Thanks
> >
> > Galina
> >
> > ___
> > cfe-commits mailing list
> > cfe-comm...@lists.llvm.org 
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > 

Re: [Lldb-commits] [cfe-dev] Upcoming upgrade of LLVM buildbot

[Andrzej Warzynski via lldb-commits]

Our Flang-aarch64 buildbots just won't connect to the main Buildbot 
master anymore. I switched them to the staging buildbot master instead 
and it seems fine for now. Is there anything that we can/should tweak at 
our end?


http://lab.llvm.org:8014/#/waterfall?tags=flang

-Andrzej

On 08/10/2020 00:31, Galina Kistanova via cfe-dev wrote:

They are online now - http://lab.llvm.org:8011/#/waterfall?tags=sanitizer

AnnotatedCommand has severe design conflict with the new buildbot.
We have changed it to be safe and still do something useful, but it will 
need more love and care.


Please let me know if you have some spare time to work on porting 
AnnotatedCommand.


Thanks

Galina

On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka > wrote:


It looks like all sanitizer builder are still offline
http://lab.llvm.org:8011/#/builders

On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits
mailto:cfe-comm...@lists.llvm.org>> wrote:

Hello everyone,

The staging buildbot was up and running for 6 days now, and
looks good.

Tomorrow at 12:00 PM PDT we will switch the production buildbot
to the new version.

If you are a bot owner, you do not need to do anything at this
point, unless I'll ask you to help.
The buildbot will go down for a short period of time, and then a
new version will come up and will accept connections from your bots.

Please note that the new version has a bit different URL
structure. You will need to update the bookmarks or scripts if
you have stored direct URLs to inside the buldbot.

We will be watching the production and staging bots and will be
improving zorg for the next week or so.

I will need your feedback about blame e-mails delivery, IRC
reporting issues, and anything you could spot wrong with the new
bot. I  hope the transition will go smoothly and we will handle
issues quickly if any would come up.

After production is good and we have about a week of running
history, I'll ask the bot owners to upgrade buildbots on their
side. Please do not upgrade your buildbots unless I'll ask you
to. We are trying to limit a number of moving parts at this
stage. We will start accepting change to zorg at this point.
Please feel free to talk to me if you will have a special
situation and if you would absolutely have to make changes.

Thanks for your support and help. And please feel free to ask if
you have questions.

Galina


On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova
mailto:gkistan...@gmail.com>> wrote:

Hello everyone,

The buildbot upgrade is entering the phase when the results
to become visible.

No change is required at this time on any of the builders.
The bot owners could upgrade the buildbot on build computers
later, at their convenience, as this is not on the critical
path.

We are going to upgrade the staging bot first. Then, once
that is stable and all detected issues are resolved, we will
upgrade the production bot.

I will need some help with testing, and will be asking to
move some of the builders temporarily to the staging. LLVM
buildbot is a piece of critical infrastructure, so more eyes
and hands in making sure it works properly the better.

I'll be posting updates and ETA of particular changes in
this thread.

Please feel free to ask if you have any questions or concerns.

Thanks

Galina

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


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


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

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Reid Kleckner via lldb-commits]

On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> They are online now - http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>
> AnnotatedCommand has severe design conflict with the new buildbot.
> We have changed it to be safe and still do something useful, but it will
> need more love and care.
>
> Please let me know if you have some spare time to work on porting
> AnnotatedCommand.
>

That's unfortunate, it would've been good to know that earlier. I and
another team member have spent a fair amount of time porting things to use
more AnnotatedCommand steps, because it gives us the flexibility to test
steps locally and make changes to the steps without restarting the buildbot
master. IMO that is the Right Way to define steps: a script that you can
run locally on a machine that satisfies the OS and dep requirements of the
script.

I am restarting the two bots that I am responsible for, and may need some
help debugging further issues soon. I'll let you know.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f21fccc - [LLDB] Fix 37 tests on Windows

[Adrian McCarthy via lldb-commits]

Author: Adrian McCarthy
Date: 2020-10-12T11:10:00-07:00
New Revision: f21fcccef7197f911a27b960aa2a180e0c7724aa

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

LOG: [LLDB] Fix 37 tests on Windows

A Windows-style LLDB_PYTHON_HOME path in a Cmake template didn't have the
backslashes escaped, which led to a garbled paths derived from it.  Fixed
by expanding the environment variable as a raw string literal.

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

Added: 


Modified: 
lldb/include/lldb/Host/Config.h.cmake

Removed: 




diff  --git a/lldb/include/lldb/Host/Config.h.cmake 
b/lldb/include/lldb/Host/Config.h.cmake
index 671d71d1c4e3..c667708a90a6 100644
--- a/lldb/include/lldb/Host/Config.h.cmake
+++ b/lldb/include/lldb/Host/Config.h.cmake
@@ -52,7 +52,7 @@
 
 #cmakedefine01 LLDB_EMBED_PYTHON_HOME
 
-#cmakedefine LLDB_PYTHON_HOME "${LLDB_PYTHON_HOME}"
+#cmakedefine LLDB_PYTHON_HOME R"(${LLDB_PYTHON_HOME})"
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 



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

[Lldb-commits] [PATCH] D89256: [LLDB] Fix 37 tests on Windows

[Adrian McCarthy via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf21fcccef719: [LLDB] Fix 37 tests on Windows (authored by 
amccarth).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89256

Files:
  lldb/include/lldb/Host/Config.h.cmake


Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -52,7 +52,7 @@
 
 #cmakedefine01 LLDB_EMBED_PYTHON_HOME
 
-#cmakedefine LLDB_PYTHON_HOME "${LLDB_PYTHON_HOME}"
+#cmakedefine LLDB_PYTHON_HOME R"(${LLDB_PYTHON_HOME})"
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 


Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -52,7 +52,7 @@
 
 #cmakedefine01 LLDB_EMBED_PYTHON_HOME
 
-#cmakedefine LLDB_PYTHON_HOME "${LLDB_PYTHON_HOME}"
+#cmakedefine LLDB_PYTHON_HOME R"(${LLDB_PYTHON_HOME})"
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89256: [LLDB] Fix 37 tests on Windows

[Jonas Devlieghere via Phabricator via lldb-commits]

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

LGTM


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

https://reviews.llvm.org/D89256

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

[Lldb-commits] [PATCH] D89256: [LLDB] Fix 37 tests on Windows

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth created this revision.
amccarth added a reviewer: JDevlieghere.
Herald added a subscriber: mgorny.
amccarth requested review of this revision.

A Windows-style LLDB_PYTHON_HOME path in a Cmake template didn't have the 
backslashes escaped, which led to a garbled paths derived from it.  Fixed by 
expanding the environment variable as a raw string literal.


https://reviews.llvm.org/D89256

Files:
  lldb/include/lldb/Host/Config.h.cmake


Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -52,7 +52,7 @@
 
 #cmakedefine01 LLDB_EMBED_PYTHON_HOME
 
-#cmakedefine LLDB_PYTHON_HOME "${LLDB_PYTHON_HOME}"
+#cmakedefine LLDB_PYTHON_HOME R"(${LLDB_PYTHON_HOME})"
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 


Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -52,7 +52,7 @@
 
 #cmakedefine01 LLDB_EMBED_PYTHON_HOME
 
-#cmakedefine LLDB_PYTHON_HOME "${LLDB_PYTHON_HOME}"
+#cmakedefine LLDB_PYTHON_HOME R"(${LLDB_PYTHON_HOME})"
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89215: [lldb] Add a page to the documentation with (external) links on how to use LLDB

[Vedant Kumar via Phabricator via lldb-commits]

vsk added a comment.

+ 1, this looks good to me.

I think there might be room to include a short (~1 sentence) summary next to 
each extension entry, so readers know what to expect before clicking on one.


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

https://reviews.llvm.org/D89215

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

[Lldb-commits] [PATCH] D89248: [lldb] [test/Register] Add read/write tests for multithreaded process

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

mgorny created this revision.
mgorny added reviewers: labath, krytarowski, emaste.
Herald added a subscriber: arichardson.
mgorny requested review of this revision.

Add a test to verify that 'register read' and 'register write' commands
work correctly in a multithreaded program, in particular that they read
or write registers for the correct thread.  The tests use locking
to ensure that events are serialized and the test can execute reliably.

// NB: I am going to use this test for initial thread support in FreeBSDRemote.


https://reviews.llvm.org/D89248

Files:
  lldb/test/Shell/Register/Inputs/x86-multithread-read.cpp
  lldb/test/Shell/Register/Inputs/x86-multithread-write.cpp
  lldb/test/Shell/Register/x86-multithread-read.test
  lldb/test/Shell/Register/x86-multithread-write.test

Index: lldb/test/Shell/Register/x86-multithread-write.test
===
--- /dev/null
+++ lldb/test/Shell/Register/x86-multithread-write.test
@@ -0,0 +1,31 @@
+# XFAIL: system-windows
+# XFAIL: system-darwin
+# REQUIRES: native && (target-x86 || target-x86_64)
+# RUN: %clangxx_host %p/Inputs/x86-gp-read.cpp -o %t -pthread
+# RUN: %lldb -b -s %s %t | FileCheck %s
+
+process launch
+# CHECK: Process {{[0-9]+}} stopped
+
+register write eax 0x05060708
+register write ebx 0x15161718
+# TODO: the need to call 'read' is probably a bug in the Linux plugin
+register read st0
+register write st0 "{0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x00 0x40}"
+
+process continue
+# CHECK-DAG: eax = 0x05060708
+# CHECK-DAG: ebx = 0x15161718
+# CHECK-DAG: st0 = { 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x00 0x40 }
+# CHECK: Process {{[0-9]+}} stopped
+
+register write eax 0x25262728
+register write ebx 0x35363738
+register read st0
+register write st0 "{0x11 0x21 0x31 0x41 0x51 0x61 0x71 0x81 0x00 0xc0}"
+
+process continue
+# CHECK-DAG: eax = 0x25262728
+# CHECK-DAG: ebx = 0x35363738
+# CHECK-DAG: st0 = { 0x11 0x21 0x31 0x41 0x51 0x61 0x71 0x81 0x00 0xc0 }
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/x86-multithread-read.test
===
--- /dev/null
+++ lldb/test/Shell/Register/x86-multithread-read.test
@@ -0,0 +1,23 @@
+# XFAIL: system-windows
+# REQUIRES: native && (target-x86 || target-x86_64)
+# RUN: %clangxx_host %p/Inputs/x86-gp-read.cpp -o %t -pthread
+# RUN: %lldb -b -s %s %t | FileCheck %s
+
+process launch
+# CHECK: Process {{[0-9]+}} stopped
+
+register read --all
+# CHECK-DAG: eax = 0x05060708
+# CHECK-DAG: ebx = 0x15161718
+# CHECK-DAG: st{{(mm)?}}0 = {0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x00 0x40}
+
+process continue
+# CHECK: Process {{[0-9]+}} stopped
+
+register read --all
+# CHECK-DAG: eax = 0x25262728
+# CHECK-DAG: ebx = 0x35363738
+# CHECK-DAG: st{{(mm)?}}0 = {0x11 0x21 0x31 0x41 0x51 0x61 0x71 0x81 0x00 0xc0}
+
+process continue
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/Inputs/x86-multithread-write.cpp
===
--- /dev/null
+++ lldb/test/Shell/Register/Inputs/x86-multithread-write.cpp
@@ -0,0 +1,66 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+std::mutex t1_mutex, t2_mutex, main_mutex;
+
+struct test_data {
+  uint32_t eax;
+  uint32_t ebx;
+
+  struct alignas(16) {
+uint8_t data[10];
+  } st0;
+};
+
+constexpr test_data filler = {
+  .eax = 0x,
+  .ebx = 0x,
+  .st0 = {{0x1f, 0x2f, 0x3f, 0x4f, 0x5f, 0x6f, 0x7f, 0x8f, 0x80, 0x40}},
+};
+
+void t_func(std::mutex _mutex) {
+  std::lock_guard t_lock(t_mutex);
+  test_data out = filler;
+
+  asm volatile(
+"finit\t\n"
+"fldt %2\t\n"
+"int3\n\t"
+"fstpt %2\t\n"
+: "+a"(out.eax), "+b"(out.ebx)
+: "m"(out.st0)
+: "memory", "st"
+  );
+
+  printf("eax = 0x%08" PRIx32 "\n", out.eax);
+  printf("ebx = 0x%08" PRIx32 "\n", out.ebx);
+  printf("st0 = { ");
+  for (int i = 0; i < sizeof(out.st0.data); ++i)
+printf("0x%02" PRIx8 " ", out.st0.data[i]);
+  printf("}\n");
+}
+
+int main() {
+  // block both threads from proceeding
+  std::unique_lock m1_lock(t1_mutex);
+  std::unique_lock m2_lock(t2_mutex);
+
+  // start both threads
+  std::thread t1(t_func, std::ref(t1_mutex));
+  std::thread t2(t_func, std::ref(t2_mutex));
+
+  // release lock on thread 1 to make it interrupt the program
+  m1_lock.unlock();
+  // wait for thread 1 to finish
+  t1.join();
+
+  // release lock on thread 2
+  m2_lock.unlock();
+  // wait for thread 2 to finish
+  t2.join();
+
+  return 0;
+}
Index: lldb/test/Shell/Register/Inputs/x86-multithread-read.cpp
===
--- /dev/null
+++ lldb/test/Shell/Register/Inputs/x86-multithread-read.cpp
@@ -0,0 +1,61 @@
+#include 
+#include 
+#include 
+
+std::mutex t1_mutex, t2_mutex, main_mutex;
+
+struct test_data {
+  uint32_t eax;
+  uint32_t ebx;
+
+  struct alignas(16) {
+uint64_t 

[Lldb-commits] [PATCH] D89124: [lldb-server][linux] Add ability to allocate memory

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D89124#2325008 , @jankratochvil 
wrote:

> In file included from 
> /home/jkratoch/redhat/llvm-monorepo/lldb/source/Host/common/NativeProcessProtocol.cpp:9:
> /home/jkratoch/redhat/llvm-monorepo/lldb/include/lldb/Host/common/NativeProcessProtocol.h:20:10:
>  fatal error: 'lldb/Utility/UnimplementedError.h' file not found
> #include "lldb/Utility/UnimplementedError.h"

That's because you need the dependant revision D89121 
  (which is now merged).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89124

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

[Lldb-commits] [PATCH] D89124: [lldb-server][linux] Add ability to allocate memory

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In file included from 
/home/jkratoch/redhat/llvm-monorepo/lldb/source/Host/common/NativeProcessProtocol.cpp:9:
/home/jkratoch/redhat/llvm-monorepo/lldb/include/lldb/Host/common/NativeProcessProtocol.h:20:10:
 fatal error: 'lldb/Utility/UnimplementedError.h' file not found
#include "lldb/Utility/UnimplementedError.h"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89124

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

[Lldb-commits] [lldb] 2d1ee7c - [lldb] Note difference in vFile:pread/pwrite format for lldb

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2020-10-12T15:09:49+01:00
New Revision: 2d1ee7cae9b2299186fa25d8d1fbdb8af482046c

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

LOG: [lldb] Note difference in vFile:pread/pwrite format for lldb

https://sourceware.org/gdb/current/onlinedocs/gdb/Host-I_002fO-Packets.html

States that all numbers should be hexidecimal but lldb
uses decimals in vFile:pread and vFile:pwrite.

lldb-server can accept either since it ends up using
strtoull which will detect the base being used.

Reviewed By: labath

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

Added: 


Modified: 
lldb/docs/lldb-platform-packets.txt

Removed: 




diff  --git a/lldb/docs/lldb-platform-packets.txt 
b/lldb/docs/lldb-platform-packets.txt
index 8d3fed7ab341..e688fc92bb7e 100644
--- a/lldb/docs/lldb-platform-packets.txt
+++ b/lldb/docs/lldb-platform-packets.txt
@@ -411,6 +411,12 @@ incompatible with the flags that gdb specifies.
 //
 //  Response is F, followed by the number of bytes read (base 10), a
 //  semicolon, followed by the data in the binary-escaped-data encoding.
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the number of bytes and offset.
+//lldb-server can process either format.
 
 
 //--
@@ -430,7 +436,11 @@ incompatible with the flags that gdb specifies.
 // 3. binary-escaped-data to be written
 //
 //  Response is F, followed by the number of bytes written (base 10)
-
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the offset. lldb-server can process either format.
 
 
 



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

[Lldb-commits] [PATCH] D89227: [lldb] Note difference in vFile:pread/pwrite format for lldb

[David Spickett via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2d1ee7cae9b2: [lldb] Note difference in vFile:pread/pwrite 
format for lldb (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89227

Files:
  lldb/docs/lldb-platform-packets.txt


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -411,6 +411,12 @@
 //
 //  Response is F, followed by the number of bytes read (base 10), a
 //  semicolon, followed by the data in the binary-escaped-data encoding.
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the number of bytes and offset.
+//lldb-server can process either format.
 
 
 //--
@@ -430,7 +436,11 @@
 // 3. binary-escaped-data to be written
 //
 //  Response is F, followed by the number of bytes written (base 10)
-
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the offset. lldb-server can process either format.
 
 
 


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -411,6 +411,12 @@
 //
 //  Response is F, followed by the number of bytes read (base 10), a
 //  semicolon, followed by the data in the binary-escaped-data encoding.
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the number of bytes and offset.
+//lldb-server can process either format.
 
 
 //--
@@ -430,7 +436,11 @@
 // 3. binary-escaped-data to be written
 //
 //  Response is F, followed by the number of bytes written (base 10)
-
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the offset. lldb-server can process either format.
 
 
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89227: [lldb] Note difference in vFile:pread/pwrite format for lldb

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/docs/lldb-platform-packets.txt:10
 defined there (vFile:size:, vFile:mode:, vFile:symlink, vFile:chmod:).
 Most importantly, the flags that lldb passes to vFile:open: are 
 incompatible with the flags that gdb specifies.

DavidSpickett wrote:
> Open flags are mentioned here and in the vFile:open description. Is that the 
> one you mean?
Oh goody. I didn't even realize we had that. Everything is fine then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89227

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

[Lldb-commits] [PATCH] D89236: [lldb] Fix bitfield "frame var" for pointers (pr47743)

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: shafik, teemperor.
Herald added a reviewer: JDevlieghere.
Herald added a project: LLDB.
labath requested review of this revision.

Displaying large packed bitfields did not work if one was accessing them
through a pointer, and he used the "->" notation ("[0]." notation is
fine). The reason for that is that implicit dereference in -> is plumbed
all the way down to ValueObjectChild::UpdateValue, where the process of
fetching the child value was forked for this flag. The bitfield
"sliding" code was implemented only for the branch which did not require
dereferencing.

This patch restructures the function to avoid this mistake. Processing
now happens in two stages.

- first the parent is dereferenced (if needed)
- then the child value is computed (this step includes sliding and is common 
for both branches)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89236

Files:
  lldb/source/Core/ValueObjectChild.cpp
  lldb/test/API/lang/c/bitfields/TestBitfields.py
  lldb/test/API/lang/c/bitfields/main.c

Index: lldb/test/API/lang/c/bitfields/main.c
===
--- lldb/test/API/lang/c/bitfields/main.c
+++ lldb/test/API/lang/c/bitfields/main.c
@@ -90,6 +90,7 @@
 
 struct LargePackedBits large_packed =
   (struct LargePackedBits){ 0xc, 0xd };
+struct LargePackedBits *large_packed_ptr = _packed;
 
 return 0;    Set break point at this line.
 
Index: lldb/test/API/lang/c/bitfields/TestBitfields.py
===
--- lldb/test/API/lang/c/bitfields/TestBitfields.py
+++ lldb/test/API/lang/c/bitfields/TestBitfields.py
@@ -147,6 +147,12 @@
 self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=["a = 0x000c", "b = 0x000deee"])
 
+# Check reading a bitfield through a pointer in various ways (PR47743)
+self.expect("v/x large_packed_ptr->b",
+substrs=["large_packed_ptr->b = 0x000d"])
+self.expect("v/x large_packed_ptr[0].b",
+substrs=["large_packed_ptr[0].b = 0x000d"])
+
 # BitFields exhibit crashes in record layout on Windows
 # (http://llvm.org/pr21800)
 @skipIfWindows
Index: lldb/source/Core/ValueObjectChild.cpp
===
--- lldb/source/Core/ValueObjectChild.cpp
+++ lldb/source/Core/ValueObjectChild.cpp
@@ -111,8 +111,7 @@
   CompilerType parent_type(parent->GetCompilerType());
   // Copy the parent scalar value and the scalar value type
   m_value.GetScalar() = parent->GetValue().GetScalar();
-  Value::ValueType value_type = parent->GetValue().GetValueType();
-  m_value.SetValueType(value_type);
+  m_value.SetValueType(parent->GetValue().GetValueType());
 
   Flags parent_type_flags(parent_type.GetTypeInfo());
   const bool is_instance_ptr_base =
@@ -120,93 +119,80 @@
(parent_type_flags.AnySet(lldb::eTypeInstanceIsPointer)));
 
   if (parent->GetCompilerType().ShouldTreatScalarValueAsAddress()) {
-lldb::addr_t addr = parent->GetPointerValue();
-m_value.GetScalar() = addr;
-
+m_value.GetScalar() = parent->GetPointerValue();
+
+switch (parent->GetAddressTypeOfChildren()) {
+case eAddressTypeFile: {
+  lldb::ProcessSP process_sp(GetProcessSP());
+  if (process_sp && process_sp->IsAlive())
+m_value.SetValueType(Value::eValueTypeLoadAddress);
+  else
+m_value.SetValueType(Value::eValueTypeFileAddress);
+} break;
+case eAddressTypeLoad:
+  m_value.SetValueType(is_instance_ptr_base
+   ? Value::eValueTypeScalar
+   : Value::eValueTypeLoadAddress);
+  break;
+case eAddressTypeHost:
+  m_value.SetValueType(Value::eValueTypeHostAddress);
+  break;
+case eAddressTypeInvalid:
+  // TODO: does this make sense?
+  m_value.SetValueType(Value::eValueTypeScalar);
+  break;
+}
+  }
+  switch (m_value.GetValueType()) {
+  case Value::eValueTypeLoadAddress:
+  case Value::eValueTypeFileAddress:
+  case Value::eValueTypeHostAddress: {
+lldb::addr_t addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
 if (addr == LLDB_INVALID_ADDRESS) {
   m_error.SetErrorString("parent address is invalid.");
 } else if (addr == 0) {
   m_error.SetErrorString("parent is NULL");
 } else {
-  m_value.GetScalar() += m_byte_offset;
-  AddressType addr_type = parent->GetAddressTypeOfChildren();
-
-  switch (addr_type) {
-  case eAddressTypeFile: {
-lldb::ProcessSP process_sp(GetProcessSP());
-if (process_sp 

[Lldb-commits] [PATCH] D89227: [lldb] Note difference in vFile:pread/pwrite format for lldb

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added inline comments.



Comment at: lldb/docs/lldb-platform-packets.txt:10
 defined there (vFile:size:, vFile:mode:, vFile:symlink, vFile:chmod:).
 Most importantly, the flags that lldb passes to vFile:open: are 
 incompatible with the flags that gdb specifies.

Open flags are mentioned here and in the vFile:open description. Is that the 
one you mean?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89227

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

[Lldb-commits] [PATCH] D89121: [lldb/Utility] Introduce UnimplementedError

[Pavel Labath via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe2f1fe361a9c: [lldb/Utility] Introduce UnimplementedError 
(authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89121

Files:
  lldb/include/lldb/Utility/UnimplementedError.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Utility/CMakeLists.txt
  lldb/source/Utility/UnimplementedError.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp

Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp
@@ -9,9 +9,9 @@
 #include "gtest/gtest.h"
 
 #include "GDBRemoteTestUtils.h"
-
 #include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h"
 #include "lldb/Utility/Connection.h"
+#include "lldb/Utility/UnimplementedError.h"
 
 namespace lldb_private {
 namespace process_gdb_remote {
@@ -39,8 +39,7 @@
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_UnimplementedError) {
   MockServerWithMockConnection server;
 
-  auto error =
-  llvm::make_error("Test unimplemented error");
+  auto error = llvm::make_error();
   server.SendErrorResponse(std::move(error));
 
   EXPECT_THAT(server.GetPackets(), testing::ElementsAre("$#00"));
@@ -61,8 +60,8 @@
 TEST(GDBRemoteCommunicationServerTest, SendErrorResponse_ErrorList) {
   MockServerWithMockConnection server;
 
-  auto error = llvm::joinErrors(llvm::make_error(),
-llvm::make_error());
+  auto error = llvm::joinErrors(llvm::make_error(),
+llvm::make_error());
 
   server.SendErrorResponse(std::move(error));
   // Make sure only one packet is sent even when there are multiple errors.
Index: lldb/source/Utility/UnimplementedError.cpp
===
--- /dev/null
+++ lldb/source/Utility/UnimplementedError.cpp
@@ -0,0 +1,11 @@
+//===-- UnimplementedError.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
+//
+//===--===//
+
+#include "lldb/Utility/UnimplementedError.h"
+
+char lldb_private::UnimplementedError::ID;
Index: lldb/source/Utility/CMakeLists.txt
===
--- lldb/source/Utility/CMakeLists.txt
+++ lldb/source/Utility/CMakeLists.txt
@@ -65,6 +65,7 @@
   StructuredData.cpp
   TildeExpressionResolver.cpp
   Timer.cpp
+  UnimplementedError.cpp
   UUID.cpp
   UriParser.cpp
   UserID.cpp
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
@@ -10,13 +10,12 @@
 
 #include "lldb/Host/Config.h"
 
-#include "GDBRemoteCommunicationServerLLGS.h"
-#include "lldb/Utility/GDBRemote.h"
 
 #include 
 #include 
 #include 
 
+#include "GDBRemoteCommunicationServerLLGS.h"
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/Debug.h"
 #include "lldb/Host/File.h"
@@ -32,11 +31,13 @@
 #include "lldb/Utility/Args.h"
 #include "lldb/Utility/DataBuffer.h"
 #include "lldb/Utility/Endian.h"
+#include "lldb/Utility/GDBRemote.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/RegisterValue.h"
 #include "lldb/Utility/State.h"
 #include "lldb/Utility/StreamString.h"
+#include "lldb/Utility/UnimplementedError.h"
 #include "lldb/Utility/UriParser.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Support/JSON.h"
@@ -2876,8 +2877,7 @@
   if (object == "features" && annex == "target.xml")
 return BuildTargetXml();
 
-  return llvm::make_error(
-  "Xfer object not supported");
+  return llvm::make_error();
 }
 
 GDBRemoteCommunication::PacketResult
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
@@ -79,18 +79,6 @@
   operator=(const GDBRemoteCommunicationServer &) = delete;
 };
 
-class 

[Lldb-commits] [lldb] e2f1fe3 - [lldb/Utility] Introduce UnimplementedError

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-10-12T13:46:17+02:00
New Revision: e2f1fe361a9c7616a1d6459b036d15f47da4a073

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

LOG: [lldb/Utility] Introduce UnimplementedError

This is essentially a replacement for the PacketUnimplementedError
previously present in the gdb-remote server code.

The reason I am introducing a generic error is because I wanted the
native process classes to be able to signal that they do not support
some functionality. They could not use PacketUnimplementedError as they
are independent of a specific transport protocol. Putting the error
class in the the native process code was also not ideal because the
gdb-remote code is also used for lldb-server's platform mode, which does
not (should not) know how to debug individual processes.

I'm putting it under Utility, as I think it can be generally useful for
notifying about unsupported/unimplemented functionality (and in
particular, for programatically testing whether something is
unsupported).

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

Added: 
lldb/include/lldb/Utility/UnimplementedError.h
lldb/source/Utility/UnimplementedError.cpp

Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Utility/CMakeLists.txt
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/UnimplementedError.h 
b/lldb/include/lldb/Utility/UnimplementedError.h
new file mode 100644
index ..c6fab0a9483c
--- /dev/null
+++ b/lldb/include/lldb/Utility/UnimplementedError.h
@@ -0,0 +1,28 @@
+//===-- UnimplementedError.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_UTILITY_UNIMPLEMENTEDERROR_H
+#define LLDB_UTILITY_UNIMPLEMENTEDERROR_H
+
+#include "llvm/Support/Errc.h"
+#include "llvm/Support/Error.h"
+
+namespace lldb_private {
+class UnimplementedError : public llvm::ErrorInfo {
+public:
+  static char ID;
+
+  void log(llvm::raw_ostream ) const override { OS << "Not implemented"; }
+
+  std::error_code convertToErrorCode() const override {
+return llvm::errc::not_supported;
+  };
+};
+} // namespace lldb_private
+
+#endif // LLDB_UTILITY_UNIMPLEMENTEDERROR_H

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
index b78f0916b9b9..60548efc0f33 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -12,11 +12,11 @@
 
 #include "GDBRemoteCommunicationServer.h"
 
-#include 
-
 #include "ProcessGDBRemoteLog.h"
 #include "lldb/Utility/StreamString.h"
 #include "lldb/Utility/StringExtractorGDBRemote.h"
+#include "lldb/Utility/UnimplementedError.h"
+#include 
 
 using namespace lldb;
 using namespace lldb_private;
@@ -113,18 +113,17 @@ GDBRemoteCommunicationServer::SendErrorResponse(const 
Status ) {
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServer::SendErrorResponse(llvm::Error error) {
+  assert(error);
   std::unique_ptr EIB;
-  std::unique_ptr PUE;
+  std::unique_ptr UE;
   llvm::handleAllErrors(
   std::move(error),
-  [&](std::unique_ptr E) { PUE = std::move(E); },
+  [&](std::unique_ptr E) { UE = std::move(E); },
   [&](std::unique_ptr E) { EIB = std::move(E); });
 
   if (EIB)
 return SendErrorResponse(Status(llvm::Error(std::move(EIB;
-  if (PUE)
-return SendUnimplementedResponse(PUE->message().c_str());
-  return SendErrorResponse(Status("Unknown Error"));
+  return SendUnimplementedResponse("");
 }
 
 GDBRemoteCommunication::PacketResult
@@ -152,5 +151,3 @@ GDBRemoteCommunicationServer::SendOKResponse() {
 bool GDBRemoteCommunicationServer::HandshakeWithClient() {
   return GetAck() == PacketResult::Success;
 }
-
-char PacketUnimplementedError::ID;

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
index a7c2ea47e3ba..63567bb9b5de 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
@@ -79,18 +79,6 @@ class 

[Lldb-commits] [PATCH] D89227: [lldb] Note difference in vFile:pread/pwrite format for lldb

[Pavel Labath via Phabricator via lldb-commits]

labath added a subscriber: jasonmolenda.
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Ah, interesting. We already know of one incompatibility in vFile packets -- it 
seems you have found a second one.

Making note of this is a good idea. The other incompatibility is mentioned in 
the Host/File.h, but mentioning it here is a good idea too. If it's not too 
much of a trouble could you also mention the open flag mismatch issue here?

PS: If you're interested, it would also be very nice to fix this these 
incompatibilities. The biggest trick is to ensure that things still work with 
old debugserver isntances (well, lldb-server too, but we don't care about that 
as much as debugserver). Fixing the flag issue is tricky and would require 
adding some explicit negotiation about the format. However, for the hex/decimal 
encoding the path forward is more clear:

- make sure consumers accept both encodings (sounds like lldb-server does -- 
debugserver would need to be checked too)
- wait a while
- change lldb client encoding


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89227

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

[Lldb-commits] [lldb] 54434dc - [nfc] [lldb] Simplify calling SymbolFileDWARF::GetDWARFCompileUnit

[Jan Kratochvil via lldb-commits]

Author: Jan Kratochvil
Date: 2020-10-12T13:26:54+02:00
New Revision: 54434dc4dce9d59c4d6cebfd87e5f67e2966573b

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

LOG: [nfc] [lldb] Simplify calling SymbolFileDWARF::GetDWARFCompileUnit

Only SymbolFileDWARF::ParseCompileUnit creates a CompileUnit and it uses
DWARFCompileUnit for that.

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

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 9f4556f791ae..3f7301871f95 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -632,8 +632,7 @@ DWARFDebugInfo ::DebugInfo() {
   return *m_info;
 }
 
-DWARFUnit *
-SymbolFileDWARF::GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit) {
+DWARFCompileUnit *SymbolFileDWARF::GetDWARFCompileUnit(CompileUnit *comp_unit) 
{
   if (!comp_unit)
 return nullptr;
 
@@ -641,7 +640,9 @@ 
SymbolFileDWARF::GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit) {
   DWARFUnit *dwarf_cu = DebugInfo().GetUnitAtIndex(comp_unit->GetID());
   if (dwarf_cu && dwarf_cu->GetUserData() == nullptr)
 dwarf_cu->SetUserData(comp_unit);
-  return dwarf_cu;
+
+  // It must be DWARFCompileUnit when it created a CompileUnit.
+  return llvm::cast_or_null(dwarf_cu);
 }
 
 DWARFDebugRanges *SymbolFileDWARF::GetDebugRanges() {
@@ -1599,8 +1600,7 @@ static uint64_t GetDWOId(DWARFCompileUnit _cu,
 llvm::Optional SymbolFileDWARF::GetDWOId() {
   if (GetNumCompileUnits() == 1) {
 if (auto comp_unit = GetCompileUnitAtIndex(0))
-  if (DWARFCompileUnit *cu = llvm::dyn_cast_or_null(
-  GetDWARFCompileUnit(comp_unit.get(
+  if (DWARFCompileUnit *cu = GetDWARFCompileUnit(comp_unit.get()))
 if (DWARFDebugInfoEntry *cu_die = cu->DIE().GetDIE())
   if (uint64_t dwo_id = ::GetDWOId(*cu, *cu_die))
 return dwo_id;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
index 76ceb279c718..019f76c67c63 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -346,7 +346,7 @@ class SymbolFileDWARF : public lldb_private::SymbolFile,
 
   lldb::CompUnitSP ParseCompileUnit(DWARFCompileUnit _cu);
 
-  virtual DWARFUnit *
+  virtual DWARFCompileUnit *
   GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit);
 
   DWARFUnit *GetNextUnparsedDWARFCompileUnit(DWARFUnit *prev_cu);



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

[Lldb-commits] [PATCH] D89165: [nfc] [lldb] Simplify calling SymbolFileDWARF::GetDWARFCompileUnit

[Jan Kratochvil via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG54434dc4dce9: [nfc] [lldb] Simplify calling 
SymbolFileDWARF::GetDWARFCompileUnit (authored by jankratochvil).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89165

Files:
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -346,7 +346,7 @@
 
   lldb::CompUnitSP ParseCompileUnit(DWARFCompileUnit _cu);
 
-  virtual DWARFUnit *
+  virtual DWARFCompileUnit *
   GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit);
 
   DWARFUnit *GetNextUnparsedDWARFCompileUnit(DWARFUnit *prev_cu);
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -632,8 +632,7 @@
   return *m_info;
 }
 
-DWARFUnit *
-SymbolFileDWARF::GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit) {
+DWARFCompileUnit *SymbolFileDWARF::GetDWARFCompileUnit(CompileUnit *comp_unit) 
{
   if (!comp_unit)
 return nullptr;
 
@@ -641,7 +640,9 @@
   DWARFUnit *dwarf_cu = DebugInfo().GetUnitAtIndex(comp_unit->GetID());
   if (dwarf_cu && dwarf_cu->GetUserData() == nullptr)
 dwarf_cu->SetUserData(comp_unit);
-  return dwarf_cu;
+
+  // It must be DWARFCompileUnit when it created a CompileUnit.
+  return llvm::cast_or_null(dwarf_cu);
 }
 
 DWARFDebugRanges *SymbolFileDWARF::GetDebugRanges() {
@@ -1599,8 +1600,7 @@
 llvm::Optional SymbolFileDWARF::GetDWOId() {
   if (GetNumCompileUnits() == 1) {
 if (auto comp_unit = GetCompileUnitAtIndex(0))
-  if (DWARFCompileUnit *cu = llvm::dyn_cast_or_null(
-  GetDWARFCompileUnit(comp_unit.get(
+  if (DWARFCompileUnit *cu = GetDWARFCompileUnit(comp_unit.get()))
 if (DWARFDebugInfoEntry *cu_die = cu->DIE().GetDIE())
   if (uint64_t dwo_id = ::GetDWOId(*cu, *cu_die))
 return dwo_id;


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -346,7 +346,7 @@
 
   lldb::CompUnitSP ParseCompileUnit(DWARFCompileUnit _cu);
 
-  virtual DWARFUnit *
+  virtual DWARFCompileUnit *
   GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit);
 
   DWARFUnit *GetNextUnparsedDWARFCompileUnit(DWARFUnit *prev_cu);
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -632,8 +632,7 @@
   return *m_info;
 }
 
-DWARFUnit *
-SymbolFileDWARF::GetDWARFCompileUnit(lldb_private::CompileUnit *comp_unit) {
+DWARFCompileUnit *SymbolFileDWARF::GetDWARFCompileUnit(CompileUnit *comp_unit) {
   if (!comp_unit)
 return nullptr;
 
@@ -641,7 +640,9 @@
   DWARFUnit *dwarf_cu = DebugInfo().GetUnitAtIndex(comp_unit->GetID());
   if (dwarf_cu && dwarf_cu->GetUserData() == nullptr)
 dwarf_cu->SetUserData(comp_unit);
-  return dwarf_cu;
+
+  // It must be DWARFCompileUnit when it created a CompileUnit.
+  return llvm::cast_or_null(dwarf_cu);
 }
 
 DWARFDebugRanges *SymbolFileDWARF::GetDebugRanges() {
@@ -1599,8 +1600,7 @@
 llvm::Optional SymbolFileDWARF::GetDWOId() {
   if (GetNumCompileUnits() == 1) {
 if (auto comp_unit = GetCompileUnitAtIndex(0))
-  if (DWARFCompileUnit *cu = llvm::dyn_cast_or_null(
-  GetDWARFCompileUnit(comp_unit.get(
+  if (DWARFCompileUnit *cu = GetDWARFCompileUnit(comp_unit.get()))
 if (DWARFDebugInfoEntry *cu_die = cu->DIE().GetDIE())
   if (uint64_t dwo_id = ::GetDWOId(*cu, *cu_die))
 return dwo_id;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Vitaly Buka via lldb-commits]

Thanks, I see them.

On Wed, 7 Oct 2020 at 16:32, Galina Kistanova  wrote:

> They are online now - http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>
> AnnotatedCommand has severe design conflict with the new buildbot.
> We have changed it to be safe and still do something useful, but it will
> need more love and care.
>
> Please let me know if you have some spare time to work on porting
> AnnotatedCommand.
>
> It's unlikely in near future.
What is missing exactly?


> Thanks
>
> Galina
>
> On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka  wrote:
>
>> It looks like all sanitizer builder are still offline
>> http://lab.llvm.org:8011/#/builders
>>
>> On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits <
>> cfe-comm...@lists.llvm.org> wrote:
>>
>>> Hello everyone,
>>>
>>> The staging buildbot was up and running for 6 days now, and looks good.
>>>
>>> Tomorrow at 12:00 PM PDT we will switch the production buildbot to the
>>> new version.
>>>
>>> If you are a bot owner, you do not need to do anything at this point,
>>> unless I'll ask you to help.
>>> The buildbot will go down for a short period of time, and then a new
>>> version will come up and will accept connections from your bots.
>>>
>>> Please note that the new version has a bit different URL structure. You
>>> will need to update the bookmarks or scripts if you have stored direct URLs
>>> to inside the buldbot.
>>>
>>> We will be watching the production and staging bots and will be
>>> improving zorg for the next week or so.
>>>
>>> I will need your feedback about blame e-mails delivery, IRC reporting
>>> issues, and anything you could spot wrong with the new bot. I  hope the
>>> transition will go smoothly and we will handle issues quickly if any would
>>> come up.
>>>
>>> After production is good and we have about a week of running history,
>>> I'll ask the bot owners to upgrade buildbots on their side. Please do
>>> not upgrade your buildbots unless I'll ask you to. We are trying to
>>> limit a number of moving parts at this stage. We will start accepting
>>> change to zorg at this point. Please feel free to talk to me if you will
>>> have a special situation and if you would absolutely have to make changes.
>>>
>>> Thanks for your support and help. And please feel free to ask if you
>>> have questions.
>>>
>>> Galina
>>>
>>>
>>> On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova 
>>> wrote:
>>>
 Hello everyone,

 The buildbot upgrade is entering the phase when the results to become
 visible.

 No change is required at this time on any of the builders. The bot
 owners could upgrade the buildbot on build computers later, at their
 convenience, as this is not on the critical path.

 We are going to upgrade the staging bot first. Then, once that is
 stable and all detected issues are resolved, we will upgrade the production
 bot.

 I will need some help with testing, and will be asking to move some of
 the builders temporarily to the staging. LLVM buildbot is a piece of
 critical infrastructure, so more eyes and hands in making sure it works
 properly the better.

 I'll be posting updates and ETA of particular changes in this thread.

 Please feel free to ask if you have any questions or concerns.

 Thanks

 Galina

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

[Lldb-commits] [PATCH] D89182: [lldb] [Process/FreeBSDRemote] Kill process via PT_KILL

[Kamil Rytarowski via Phabricator via lldb-commits]

krytarowski added a comment.

In D89182#2324267 , @labath wrote:

> FWIW, PTHREAD_KILL is strongly discouraged on linux. But if the situation is 
> different on freebsd, then fine.

I think you mean PTRACE_KILL. PT_KILL is fine for BSDs and in case when it is 
not, it should be fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89182

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

[Lldb-commits] [PATCH] D89227: [lldb] Note different vFile:pread/pwrite format for lldb

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a reviewer: labath.
DavidSpickett added a comment.

This is the compatibility issue I mentioned in the other review. I found it 
investigating why remotely debugging lldb would work with lldb but not gdb, 
turned out to be a >2gb file causing it but I saw the different formats in the 
logs.

Source for the gdb side is  binutils-gdb/gdbserver/hostio.cc::handle_pread. 
Which calls require_int, which tries to convert from hex.

lldb-server side is in 
source/plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp::Handle_vFile_pRead
and for lldb in 
source/plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp::ReadFile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89227

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

[Lldb-commits] [PATCH] D82863: [LLDB] Add support to resize SVE registers at run-time

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

In D82863#2321647 , @labath wrote:

> In D82863#2321370 , @omjavaid wrote:
>
>> In D82863#2320342 , @jasonmolenda 
>> wrote:
>>
>>> The original g/G packets were designed for little embedded systems where 
>>> the stub had to be very small and dumb, and could just memcpy the payload 
>>> in the packet into the register context & back out again.  Any sensible 
>>> design today would, at least, have some form of an array of regnum:regval 
>>> to eliminate many of the problems.
>>>
 Unless of course, we make sure SVE regs come last, but that imposes some 
 constraints on future registers sets. I suppose we might be able to say 
 that all variable-length or otherwise-funny registers must come last.
>>>
>>> Yeah, Omair's patch currently assumes that the SVE regs come last already 
>>> when they copy & truncate the registers context to heap.  I fear that we'll 
>>> get to armv12 and we'll be adding registers after the SVE and wonder why 
>>> they're being truncated somewhere in lldb. :)
>
> Well.. we could design it such that the SVE registers (and any other 
> dynamically-sized regs) always come last. Then they wouldn't impact the 
> offsets of static registers.
>
> I don't think we have a requirement that newer register sets must be 
> appended. Or at least, we shouldn't have, as now both intel and arm have cpu 
> features (and registers) that may be arbitrarily combined in future 
> processors.

For now I am considering variable sized registers i-e SVE Z and P registers to 
always come last which is currently the case and will be in future patches 
which add support for Pointer Authentication and MTE registers.

>>> @omjavaid , what do you think about disabling g/G when we're working with 
>>> SVE registers (GDBRemoteCommunicationClient::AvoidGPackets)?  There are 
>>> some gdb-remote stubs that can *only* read/write registers with g/G, but I 
>>> think it's reasonable to say "you must implement p/P for a target with 
>>> SVE", that's a generic packet shared by both lldb and gdb.  We could add a 
>>> more-modern g/G replacement packet, but no one would have that implemented, 
>>> and if they were going to add anything, I'd have them implement p/P unless 
>>> it's perf problems and they need a read-all-registers / write-all-registers 
>>> packet that works with SVE.

Just scrolling through GDB log one of the answers about target XML is that 
target XML is not exchanged for native connection where gdbserver is not being 
used. For gdbserver connection, target xml is exchanged onces per connection 
and register sizes are updated based on vg after that internally. However 
testing gdb with same executable as the one I wrote for LLDB was having gdb 
remote connection crash which could be something to do with SVE or some other 
bug.

>> I did consider and second the idea of pulling out SVE registers from g/G 
>> packet specially for vector length that is more than 8 x (32 bytes) as it 
>> creates a huge sized g/G packet containing thousands of bytes. Historically, 
>> sending multiple p/P for all registers was an overhead due to slow 
>> communication between embedded or serially connected remote targets and host 
>> gdb/GDB. This is mostly not the case these days
>
> While it's certainly less important than it used to be, there are still 
> people who care about these things. Just last year, we had a contribution 
> which started using them more aggressively. The contributor has a use case 
> for fetching all registers on each stop, which meant that our usual 
> expedition rules were not sufficient and p packets were slow.
>
>> and we can come up with an alternate approach here as being discussed above.
>
> That's true, but any custom solution is unlikely to be supported by stubs 
> (qemu) which are primarily meant for communicating with gdb. And since we 
> have people who want to use those stubs with lldb (and I am supporting some 
> of them), if we do something custom, it's possible we may end up supporting 
> both.

As far as I see when a stub like QEMU or OpenOCD goes on to add SVE registers 
support with dynamic resizing they will have to provide a basic target XML at 
startup plus the ability to change the size and offsets of SVE registers on 
their end plus communicate any vg update to LLDB so that LLDB client side can 
update its version of target register infos with new SVE register sizes and 
offset. Offsets should be relative to vg offset, that is Z register should 
start right after vg register and will sizes (8 bytes times vg value). In 
current implementation This will look like we have payload after VG register 
which has a size relative to current VG size.

> That's why I'd like to understand more about how gdb does things. The g 
> packet definitely has its issues but so does introducing custom packets, and 
> I think we should weigh 

[Lldb-commits] [PATCH] D89227: [lldb] Note different vFile:pread/pwrite format for lldb

[David Spickett via Phabricator via lldb-commits]

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

https://sourceware.org/gdb/current/onlinedocs/gdb/Host-I_002fO-Packets.html

States that all numbers should be hexidecimal but lldb
uses decimals in vFile:pread and vFile:pwrite.

lldb-server can accept either since it ends up using
strtoull which will detect the base being used.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89227

Files:
  lldb/docs/lldb-platform-packets.txt


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -411,6 +411,12 @@
 //
 //  Response is F, followed by the number of bytes read (base 10), a
 //  semicolon, followed by the data in the binary-escaped-data encoding.
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the number of bytes and offset.
+//lldb-server can process either format.
 
 
 //--
@@ -430,7 +436,11 @@
 // 3. binary-escaped-data to be written
 //
 //  Response is F, followed by the number of bytes written (base 10)
-
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the offset. lldb-server can process either format.
 
 
 


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -411,6 +411,12 @@
 //
 //  Response is F, followed by the number of bytes read (base 10), a
 //  semicolon, followed by the data in the binary-escaped-data encoding.
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the number of bytes and offset.
+//lldb-server can process either format.
 
 
 //--
@@ -430,7 +436,11 @@
 // 3. binary-escaped-data to be written
 //
 //  Response is F, followed by the number of bytes written (base 10)
-
+//
+//  COMPATIBILITY
+//The gdb-remote serial protocol documentation says that numbers
+//in "vFile:" packets should be hexidecimal. Instead lldb uses
+//decimal for the offset. lldb-server can process either format.
 
 
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89124: [lldb-server][linux] Add ability to allocate memory

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1354
+  auto region_it = llvm::find_if(m_mem_region_cache, [](const auto ) {
+return pair.first.GetExecutable() == MemoryRegionInfo::eYes;
+  });

jankratochvil wrote:
> Finding arbitrary address would not be safe if LLDB supports [[ 
> https://lldb.llvm.org/status/projects.html#non-stop-debugging | non-stop mode 
> if implemented ]]. It also makes the address a bit non-deterministic. IIRC 
> GDB is using executable's e_entry (="_start" if it exists). But I do not have 
> any strong reason for that.
> 
Lldb also uses the program entry point for the "call mmap(...)" approach of 
allocating memory. That is a pretty good choice when one needs to find a line 
of code that will not be executed during normal program operation (not stop or 
otherwise). However:
- here we don't need that requirement (for all-stop mode, anyway), as we're not 
calling any function (even mmap can execute a fair amount of code). We're just 
executing a single instruction.
- technically, there's nothing preventing the application from unmapping the 
entry point address, or reusing it for something else. If I wanted a foolproof 
solution, I'd still need to implement a fallback algorithm (as well as the code 
to search for the entry point, as we right now don't have anything that 
lldb-server could use).

Given that, it seems better to just go for the more complete solution straight 
away. It's true that this makes the address harder to predict (I'm trying not 
to use the word nondeterministic, because that's not really it), but such is 
life. And coming up with a non-stop-compatible solution for this is so 
complicated that I'd leave this for some other time (worst case: we disable 
this feature, or force a temporary stop of all threads).



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1400
+.ToError())
+return std::move(Err);
+

DavidSpickett wrote:
> Is it possible that the page we find is executable but not writeable and is 
> this part intended to handle that?
> (maybe this is a silly question, the code had to be written into that page in 
> the first place I guess)
Ptrace bypasses normal write-protection checks (~all code is not writable these 
days, and we wouldn't be able to set breakpoints otherwise), so checking for 
writable addresses would not be useful.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1404
+
+  int req = SupportHardwareSingleStepping() ? PTRACE_SINGLESTEP : PTRACE_CONT;
+  if (llvm::Error Err =

DavidSpickett wrote:
> Could you add a comment here explaining this? Like "either we single step 
> just syscall, or continue then hit a trap instruction after the syscall"
> (if I have that right)
> 
> The description for PTRACE_SINGLESTEP confused me a bit with "next entry to":
> > Restart the stopped tracee as for PTRACE_CONT, but arrange for
> > the tracee to be stopped at the next entry to or exit from a
> > system call, or after execution of a single instruction,
> > respectively.
> 
> But I assume what happens here is you step "syscall" and then the whole mmap 
> call happens, then you come back. Instead of getting kept before the mmap 
> actually happens.
> 
> 
Yes, that's exactly what happens. Ptrace can't step "into" the kernel. The 
reason that description is confusing is because it a description of both 
PTRACE_SINGLESTEP *and* PTRACE_SYSCALL, with the latter stopping before the 
syscall.

I've considered using a sequence of two PTRACE_SYSCALLs to avoid the trap 
instruction requirement, but it wasn't clear to me that this would help in any 
way (and it would make the code longer).



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1419
+  uint64_t result = reg_ctx.ReadRegisterAsUnsigned(syscall_data.Result, 
-ESRCH);
+  uint64_t errno_threshold =
+  (uint64_t(-1) >> (64 - 8 * m_arch.GetAddressByteSize())) - 0x1000;

DavidSpickett wrote:
> What does this calculation do/mean? (0x1000 is 4k which is a page size maybe?)
This is the linux syscall convention for returning errors. The fact that it 
matches the page size is probably not accidental, though it was not strictly 
necessary.

I've added a short comment to elaborate.



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1421
+  (uint64_t(-1) >> (64 - 8 * m_arch.GetAddressByteSize())) - 0x1000;
+  if (result > errno_threshold) {
+return llvm::errorCodeToError(

DavidSpickett wrote:
> For these ifs, are you putting {} because the return is split over two lines? 
> I think it would compile without but is this one of the exceptions to the 
> coding standard? (if clang-format isn't doing this for you that is)
clang-format never adds new tokens -- it just reformats 

[Lldb-commits] [PATCH] D89124: [lldb-server][linux] Add ability to allocate memory

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 297523.
labath added a comment.

address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89124

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/test/API/lang/c/stepping/TestStepAndBreakpoints.py
  lldb/test/API/tools/lldb-server/memory-allocation/Makefile
  
lldb/test/API/tools/lldb-server/memory-allocation/TestGdbRemoteMemoryAllocation.py
  lldb/test/API/tools/lldb-server/memory-allocation/main.c
  lldb/test/Shell/Expr/nodefaultlib.cpp
  lldb/unittests/TestingSupport/Host/NativeProcessTestUtils.h

Index: lldb/unittests/TestingSupport/Host/NativeProcessTestUtils.h
===
--- lldb/unittests/TestingSupport/Host/NativeProcessTestUtils.h
+++ lldb/unittests/TestingSupport/Host/NativeProcessTestUtils.h
@@ -41,9 +41,6 @@
   MOCK_METHOD0(Detach, Status());
   MOCK_METHOD1(Signal, Status(int Signo));
   MOCK_METHOD0(Kill, Status());
-  MOCK_METHOD3(AllocateMemory,
-   Status(size_t Size, uint32_t Permissions, addr_t ));
-  MOCK_METHOD1(DeallocateMemory, Status(addr_t Addr));
   MOCK_METHOD0(GetSharedLibraryInfoAddress, addr_t());
   MOCK_METHOD0(UpdateThreads, size_t());
   MOCK_CONST_METHOD0(GetAuxvData,
@@ -147,4 +144,4 @@
 };
 } // namespace lldb_private
 
-#endif
\ No newline at end of file
+#endif
Index: lldb/test/Shell/Expr/nodefaultlib.cpp
===
--- /dev/null
+++ lldb/test/Shell/Expr/nodefaultlib.cpp
@@ -0,0 +1,16 @@
+// Test that we're able to evaluate expressions in inferiors without the
+// standard library (and mmap-like functions in particular).
+
+// REQUIRES: native
+// XFAIL: system-linux && !(target-x86 || target-x86_64)
+// XFAIL: system-netbsd || system-freebsd
+
+// RUN: %build %s --nodefaultlib -o %t
+// RUN: %lldb %t -o "b main" -o run -o "p call_me(5, 6)" -o exit \
+// RUN:   | FileCheck %s
+
+// CHECK: (int) $0 = 30
+
+int call_me(int x, long y) { return x * y; }
+
+int main() { return call_me(4, 5); }
Index: lldb/test/API/tools/lldb-server/memory-allocation/main.c
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-allocation/main.c
@@ -0,0 +1 @@
+int main() { return 0; }
Index: lldb/test/API/tools/lldb-server/memory-allocation/TestGdbRemoteMemoryAllocation.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-allocation/TestGdbRemoteMemoryAllocation.py
@@ -0,0 +1,101 @@
+
+import gdbremote_testcase
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+supported_linux_archs = ["x86_64", "i386"]
+supported_oses = ["linux"]
+
+class TestGdbRemoteMemoryAllocation(gdbremote_testcase.GdbRemoteTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def allocate(self, size, permissions):
+self.test_sequence.add_log_lines(["read packet: $_M{:x},{}#00".format(size, permissions),
+  {"direction": "send",
+   "regex":
+   r"^\$([0-9a-f]+)#[0-9a-fA-F]{2}$",
+   "capture": {
+   1: "addr"}},
+  ],
+ True)
+context = self.expect_gdbremote_sequence()
+self.assertIsNotNone(context)
+
+addr = int(context.get("addr"), 16)
+self.test_sequence.add_log_lines(["read packet: $qMemoryRegionInfo:{:x}#00".format(addr),
+  {"direction": "send",
+   "regex":
+   r"^\$start:([0-9a-fA-F]+);size:([0-9a-fA-F]+);permissions:([rwx]*);.*#[0-9a-fA-F]{2}$",
+   "capture": {
+   1: "addr",
+   2: "size",
+  

[Lldb-commits] [PATCH] D89193: [lldb] [Process/FreeBSDRemote] Support YMM reg via PT_*XSTATE

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I assume this fixes some of the tests we have already, but it would be good to 
mention that in the description.




Comment at: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp:479
+  case XSaveRegSet:
+// TODO: can WriteRegisterSet() ever be called without ReadRegisterSet()?
+assert(m_xsave.size() > 0);

mgorny wrote:
> @labath, is this a safe assumption to make? Generally, if `ReadRegisterSet()` 
> is not called, `m_xsave` will be zero-sized.
Interesting question. I don't really have an answer to that. Somebody obviously 
should fill out `m_xsave` before calling this function, but maybe it doesn't 
have to be `ReadRegisterSet()`? What will happen if the client sends a `G` 
packet before reading any registers?

That said, I'm not particularly troubled by this assertion. I wouldn't be 
surprised if we already had code making that assumption without even realizing 
it.


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

https://reviews.llvm.org/D89193

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

[Lldb-commits] [PATCH] D89182: [lldb] [Process/FreeBSDRemote] Kill process via PT_KILL

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.
Herald added a subscriber: JDevlieghere.

FWIW, PTHREAD_KILL is strongly discouraged on linux. But if the situation is 
different on freebsd, then fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89182

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

[Lldb-commits] [PATCH] D88769: [trace] Scaffold "thread trace dump instructions"

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.



Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp:61
+ const std::vector ) {
+  TraceSP trace_instance(new TraceIntelPT(pt_cpu, targets));
+  for (const TargetSP _sp : targets)

wallace wrote:
> labath wrote:
> > auto trace_instance = std::make_shared(...)
> I can't do this because the constructor is private (specifically to 
> std::shared_ptr).
> I want to have this method as the main way to create instances because I need 
> to use shared_ptr of this instance to set up everything correctly, and I 
> can't do it from the constructor itself.
> I've checked ways to make std::make_shared(...), but it looks 
> like too much code that outweighs the benefit of the fancy allocator.
Ah, cool. Sorry for the noise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88769

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

[Lldb-commits] [PATCH] D89165: [nfc] [lldb] Simplify calling SymbolFileDWARF::GetDWARFCompileUnit

[Pavel Labath via Phabricator via lldb-commits]

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

Makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89165

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