[Lldb-commits] [PATCH] D107182: [LLDB][GUI] Refactor form drawing using subsurfaces

2021-08-06 Thread Omar Emara via Phabricator via lldb-commits
OmarEmaraDev added a comment.

@jasonmolenda `is_pad` is defined by ncurses. According to the man page,  it is 
an extension that is `not supported on Version 7, BSD or System V 
implementations.`, but that shouldn't be a problem as far as I know. Can you 
maybe check the ncurses header and see if it is there?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107182

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


[Lldb-commits] [PATCH] D107182: [LLDB][GUI] Refactor form drawing using subsurfaces

2021-08-06 Thread Omar Emara via Phabricator via lldb-commits
OmarEmaraDev added a comment.

`is_pad` was added in 2009 in ncurses 5.7 - patch 20090906. So it is 
sufficiently old to be used, is it not?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107182

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


[Lldb-commits] [PATCH] D107625: Add a stack-memory-only style for Darwin process save-core

2021-08-06 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda created this revision.
jasonmolenda added a project: LLDB.
Herald added a subscriber: JDevlieghere.
jasonmolenda requested review of this revision.

After adding the "dirty memory only" coredump style, I've been wondering how 
small a corefile I could get by only saving stack memory.  I took a little time 
today to find out.  A normal macOS corefile is a couple of GB, a dirty-memory 
corefile is around 440kb for a test binary.  A stack memory corefile is about 
20kb for that test binary.

I added a new "type" key-value pair to the qMemoryRegionInfo packet, and add 
"stack" to stack memory regions.  David added a "flags" k-v pair for MTE but 
that has a specially formatted string of MTE flags in it (space separated) so I 
didn't want to mix in with that.  It's straightforward to detect different 
memory types on Darwin systems, but I haven't thought of anything useful I 
could do by writing out heap dirty memory only or something.  Maybe someone 
will think of some interesting way to use the memory region types.

In the test case, I create a stack-memory-only corefile, then read it back into 
lldb and fetch some stack & heap objects.  SBValue has the unfortunate behavior 
(IMO) that it doesn't surface memory read errors in any way - so you can ask 
for a summary or a value of an SBValue object that couldn't read anything, and 
it will return 0/empty-string.  We need to surface memory read errors better in 
lldb in these cases, this is just one of the issues with that.

I'm not sure a stack-memory-only corefile is especially useful for real 
C++/ObjC/Swift programs where many objects live on the heap.  One thing I've 
thought about is trying to get a very tiny corefile showing interesting unwind 
states for writing tests against.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107625

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Target/MemoryRegionInfo.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/test/API/macosx/skinny-corefile/TestSkinnyCorefile.py
  lldb/test/API/macosx/stack-corefile/Makefile
  lldb/test/API/macosx/stack-corefile/TestStackCorefile.py
  lldb/test/API/macosx/stack-corefile/main.c
  lldb/tools/debugserver/source/DNBDefs.h
  lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
  lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
  lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
  lldb/tools/debugserver/source/RNBRemote.cpp

Index: lldb/tools/debugserver/source/RNBRemote.cpp
===
--- lldb/tools/debugserver/source/RNBRemote.cpp
+++ lldb/tools/debugserver/source/RNBRemote.cpp
@@ -4310,6 +4310,8 @@
   }
 }
 ostrm << ";";
+if (region_info.is_stack)
+  ostrm << "type:stack;";
   }
   return SendPacket(ostrm.str());
 }
Index: lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
===
--- lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
+++ lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
@@ -40,6 +40,7 @@
   vm_prot_t prot);
   bool RestoreProtections();
   bool GetRegionForAddress(nub_addr_t addr);
+  bool GetIsStackMemory() const;
 
   uint32_t GetDNBPermissions() const;
 
Index: lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
===
--- lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
+++ lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
@@ -182,3 +182,11 @@
 dnb_permissions |= eMemoryPermissionsExecutable;
   return dnb_permissions;
 }
+
+bool MachVMRegion::GetIsStackMemory() const {
+  // VM_MEMORY_STACK and VM_PROT_NONE is the STACK GUARD region.
+  if (m_data.user_tag == VM_MEMORY_STACK && m_data.protection != VM_PROT_NONE)
+return true;
+  else
+return false;
+}
Index: lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
===
--- lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
+++ lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
@@ -125,6 +125,8 @@
 region_info->permissions = vmRegion.GetDNBPermissions();
 region_info->dirty_pages =
 get_dirty_pages(task, vmRegion.StartAddress(), vmRegion.GetByteSize());
+if (vmRegion.GetIsStackMemory())
+  region_info->is_stack = true;
   } else {
 region_info->addr = address;
 region_info->size = 0;
Index: lldb/tools/debugserver/source/DNBDefs.h
===
--- lldb/tools/debugserver/source/DNBDefs.h
+++ lldb/tools/debugserver/source/DNBDefs.h
@@ -318,11 +318,13 @@
 
 struct DNBRegionInfo {
 public:
-  DNBRegionInfo() : addr(0), size(0), permissions(0), dirty_pages() {}
+  DNBRegionInfo()
+  : addr(0), s

[Lldb-commits] [PATCH] D107182: [LLDB][GUI] Refactor form drawing using subsurfaces

2021-08-06 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added a comment.

In D107182#2930541 , @OmarEmaraDev 
wrote:

> `is_pad` was added in 2009 in ncurses 5.7 - patch 20090906. So it is 
> sufficiently old to be used, is it not?

Thanks Omar, I didn't know that.  I was building on macOS 11.5.1 (current 
newest release version).  Looking at our curses.h, it looks like we have a 
slightly-too-old version of 5.7:

  #define NCURSES_VERSION_MAJOR 5
  #define NCURSES_VERSION_MINOR 7
  #define NCURSES_VERSION_PATCH 20081102

is_pad isn't in the header or in the libcurses solib.  And our next major 
version, macOS 12, is using the same version. :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107182

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


[Lldb-commits] [PATCH] D107625: Add a stack-memory-only style for Darwin process save-core

2021-08-06 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 364731.
jasonmolenda added a comment.

Handle a bit of state tracking in ObjectFileMachO a little bit more readably.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107625

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Target/MemoryRegionInfo.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/test/API/macosx/skinny-corefile/TestSkinnyCorefile.py
  lldb/test/API/macosx/stack-corefile/Makefile
  lldb/test/API/macosx/stack-corefile/TestStackCorefile.py
  lldb/test/API/macosx/stack-corefile/main.c
  lldb/tools/debugserver/source/DNBDefs.h
  lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
  lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
  lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
  lldb/tools/debugserver/source/RNBRemote.cpp

Index: lldb/tools/debugserver/source/RNBRemote.cpp
===
--- lldb/tools/debugserver/source/RNBRemote.cpp
+++ lldb/tools/debugserver/source/RNBRemote.cpp
@@ -4310,6 +4310,8 @@
   }
 }
 ostrm << ";";
+if (region_info.is_stack)
+  ostrm << "type:stack;";
   }
   return SendPacket(ostrm.str());
 }
Index: lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
===
--- lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
+++ lldb/tools/debugserver/source/MacOSX/MachVMRegion.h
@@ -40,6 +40,7 @@
   vm_prot_t prot);
   bool RestoreProtections();
   bool GetRegionForAddress(nub_addr_t addr);
+  bool GetIsStackMemory() const;
 
   uint32_t GetDNBPermissions() const;
 
Index: lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
===
--- lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
+++ lldb/tools/debugserver/source/MacOSX/MachVMRegion.cpp
@@ -182,3 +182,11 @@
 dnb_permissions |= eMemoryPermissionsExecutable;
   return dnb_permissions;
 }
+
+bool MachVMRegion::GetIsStackMemory() const {
+  // VM_MEMORY_STACK and VM_PROT_NONE is the STACK GUARD region.
+  if (m_data.user_tag == VM_MEMORY_STACK && m_data.protection != VM_PROT_NONE)
+return true;
+  else
+return false;
+}
Index: lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
===
--- lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
+++ lldb/tools/debugserver/source/MacOSX/MachVMMemory.cpp
@@ -125,6 +125,8 @@
 region_info->permissions = vmRegion.GetDNBPermissions();
 region_info->dirty_pages =
 get_dirty_pages(task, vmRegion.StartAddress(), vmRegion.GetByteSize());
+if (vmRegion.GetIsStackMemory())
+  region_info->is_stack = true;
   } else {
 region_info->addr = address;
 region_info->size = 0;
Index: lldb/tools/debugserver/source/DNBDefs.h
===
--- lldb/tools/debugserver/source/DNBDefs.h
+++ lldb/tools/debugserver/source/DNBDefs.h
@@ -318,11 +318,13 @@
 
 struct DNBRegionInfo {
 public:
-  DNBRegionInfo() : addr(0), size(0), permissions(0), dirty_pages() {}
+  DNBRegionInfo()
+  : addr(0), size(0), permissions(0), dirty_pages(), is_stack(false) {}
   nub_addr_t addr;
   nub_addr_t size;
   uint32_t permissions;
   std::vector dirty_pages;
+  bool is_stack;
 };
 
 enum DNBProfileDataScanType {
Index: lldb/test/API/macosx/stack-corefile/main.c
===
--- /dev/null
+++ lldb/test/API/macosx/stack-corefile/main.c
@@ -0,0 +1,15 @@
+#include 
+#include 
+#include 
+int main() {
+  int stack_int = 5;
+  int *heap_int = (int*) malloc(sizeof (int));
+  *heap_int = 10;
+
+  char stack_str[80];
+  strcpy (stack_str, "stack string");
+  char *heap_str = (char*) malloc(80);
+  strcpy (heap_str, "heap string");
+
+  return stack_int; // break here;
+}
Index: lldb/test/API/macosx/stack-corefile/TestStackCorefile.py
===
--- /dev/null
+++ lldb/test/API/macosx/stack-corefile/TestStackCorefile.py
@@ -0,0 +1,69 @@
+"""Test that lldb can create a stack-only corefile, and load the main binary."""
+
+import os
+import re
+import subprocess
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestStackCorefile(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+@skipUnlessDarwin
+def test(self):
+
+corefile = self.getBuildArtifact("process.core")
+self.build()
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "// bre

[Lldb-commits] [PATCH] D107182: [LLDB][GUI] Refactor form drawing using subsurfaces

2021-08-06 Thread Omar Emara via Phabricator via lldb-commits
OmarEmaraDev added a comment.

@jasonmolenda Okay, I will just reimplement the patch without `is_pad` somehow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107182

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


[Lldb-commits] [PATCH] D107182: [LLDB][GUI] Refactor form drawing using subsurfaces

2021-08-06 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added a comment.

In D107182#2930666 , @OmarEmaraDev 
wrote:

> @jasonmolenda Okay, I will just reimplement the patch without `is_pad` 
> somehow.

Thanks!  Sorry it's so very old.  :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107182

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


[Lldb-commits] [PATCH] D105182: [lldb] Add "memory tag write" command

2021-08-06 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added a comment.

> Many different types of memory tagging exist, MTE is but one.

Sure. I'm not opposed to making changes to adapt to the properties of different 
tags. However the most concrete one I have access to it MTE so that has shaped 
the initial support and assumptions.

> CHERI uses memory tagging for something completely different (tracking valid 
> capability, ie pointer provenance), and its tags make sense to read (though 
> are a property of the stored data, not the memory allocation), but not 
> explicitly write (only implicitly by writing a capability to the associated 
> location, which will include the non-addressable tag bit), as that is 
> architecturally forbidden in order to ensure that the hardware-enforced tags 
> can never be corrupted by software.

Definitely we could add properties to the tagging scheme information to disable 
the read and/or/write commands. Something like:

  (lldb) memory tag write 0x12341234 23
  Error: Cannot write memory tags for address 0x12341234.  tags are not 
writeable by user software

If you mean hiding the commands completely from the interactive sessions, 
there's no existing mechanism for it but you could make the argument for it. 
The current pattern is to show the command but error saying that it is 
unsupported. (this also happens when a remote doesn't support some feature)

> Moreover, in future, CHERI and MTE will be composed (there is ongoing 
> experimental work to investigate doing so on CHERI-RISC-V, and if Arm's 
> experimental Morello prototype is adopted in a future version of the Arm 
> architecture it will also have to compose with MTE). See also the core dump 
> format for MTE tags, which specifies the _type_ of tag, specifically to 
> accommodate other uses of tagged memory.

Certainly. There's nothing stopping us supporting such a configuration apart 
from (at least personally) zero experience or way to test such a thing. 
Something like:

  (lldb) memory read foo
  Error: Current process has multiple memory tag types. "foo", "bar". Please 
select one with the --type argument.

It's not something I could really implement with just MTE as the vast majority 
of the code would be untested but with a use case we could definitely make the 
changes.

Where this does become more thorny is the lldb API where we have more stringent 
commitments to not changing it. Happily, I haven't started on this yet and your 
concerns very much need to be included.

Perhaps you could write up something and post it to the lldb-dev list for more 
visibility? I'd be interested to know how things work in the existing lldb 
cheri port (I assume there is one, there is for Morello at least).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105182

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


[Lldb-commits] [PATCH] D107213: Disassemble AArch64 pc-relative address calculations & symbolicate

2021-08-06 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments.



Comment at: lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp:1328
+(m_adrp_insn & 0x9f00) == 0x9000 &&
+(m_adrp_insn & 0x1f) == ((value >> 5) & 0x1f)) {
+  // Bitmasking lifted from MachODump.cpp's SymbolizerSymbolLookUp.

jasonmolenda wrote:
> DavidSpickett wrote:
> > Add comments to these two lines saying what they're checking for.
> > 
> > (looks correct from what the ARMARM says)
> There's a comment right before the conditional expr which says what it's 
> checking.  The check that m_adrp_insn is actually an adrp instruction is 
> unnecessary; I cribbed that from the MachODump file, but the only way I set 
> the ivar to the instruction is if we had 
> type_ptr==LLVMDisassembler_ReferenceType_In_ARM64_ADRP in the previous 
> instruction.
> The check that m_adrp_insn is actually an adrp instruction is unnecessary

In that we could have an Optional and assume if set, it's an adrp. 
But this is functionally the same.

Comment bikeshedding, put the conditions in the same order as the text? So 
readers know that 0x1f is the register?
(though if you were questioning this code the first port of call would be the 
arm manuals but regardless)
```
// If previous instruction was ADRP and this is ADD, and it's to
// the same register, this is pc-relative address calculation.
if (m_adrp_address == pc - 4 &&
(m_adrp_insn & 0x9f00) == 0x9000 && 
*type_ptr == LLVMDisassembler_ReferenceType_In_ARM64_ADDXri &&
(m_adrp_insn & 0x1f) == ((value >> 5) & 0x1f)) {
```



Comment at: 
lldb/test/API/functionalities/disassemble/aarch64-adrp-add/TestAArch64AdrpAdd.py:15-27
+src_dir = self.getSourceDir()
+yaml_path = os.path.join(src_dir, "a.out-arm64.yaml")
+obj_path = self.getBuildArtifact("a.out-arm64")
+self.yaml2obj(yaml_path, obj_path)
+
+target = self.dbg.CreateTarget(obj_path)
+self.assertTrue(target, VALID_TARGET)

Could move most of this into a utility fn too.



Comment at: 
lldb/test/API/functionalities/disassemble/aarch64-adrp-add/TestAArch64AdrpAdd.py:29
+
+def test_arm64_32(self):
+src_dir = self.getSourceDir()

`no_debug_info_test` here?



Comment at: 
lldb/test/API/functionalities/disassemble/aarch64-adrp-add/TestAArch64AdrpAdd.py:60
+if found_hi_string == False or found_foo == False:
+print('Did not find "HI" string or "foo" in disassembly 
symbolication in %s' % binaryname)
+if self.TraceOn():

Shouldn't this be within the if Trace?



Comment at: 
lldb/test/API/functionalities/disassemble/aarch64-adrp-add/main.c:260
+  asm("nop");asm("nop");asm("nop");asm("nop");
+  asm("nop");asm("nop");asm("nop");asm("nop");
+  return 5;

I admit a bit of a "wat" moment here, but I assume this is setting things up so 
that foo is some distance behind (at a lower address) than main?
So we have foo, which is before main and HI which is after for a negative, 
positive offset.

Could do with a comment for how many instructions this is. Maybe you could 
#define something for maybe 64 nops at a time just to make it a little less 
verbose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107213

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


[Lldb-commits] [PATCH] D107475: [lldb] [gdb-remote] Use hexadecimal numbers in vFile packets for GDB compliance

2021-08-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 364781.
mgorny added a comment.

Add tests for server and client. Fix error handling.


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

https://reviews.llvm.org/D107475

Files:
  lldb/docs/lldb-platform-packets.txt
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
  lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py

Index: lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
@@ -0,0 +1,215 @@
+from __future__ import print_function
+
+# lldb test suite imports
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import TestBase
+
+# gdb-remote-specific imports
+import lldbgdbserverutils
+from gdbremote_testcase import GdbRemoteTestCaseBase
+
+import binascii
+import stat
+import tempfile
+
+
+class TestGdbRemotePlatformFile(GdbRemoteTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_platform_file_rdonly(self):
+self.vFile_test(read=True)
+
+def test_platform_file_wronly(self):
+self.vFile_test(write=True)
+
+def test_platform_file_rdwr(self):
+self.vFile_test(read=True, write=True)
+
+def test_platform_file_wronly_append(self):
+self.vFile_test(write=True, append=True)
+
+def test_platform_file_rdwr_append(self):
+self.vFile_test(read=True, write=True, append=True)
+
+def test_platform_file_wronly_trunc(self):
+self.vFile_test(write=True, trunc=True)
+
+def test_platform_file_rdwr_trunc(self):
+self.vFile_test(read=True, write=True, trunc=True)
+
+def test_platform_file_wronly_creat(self):
+self.vFile_test(write=True, creat=True)
+
+def test_platform_file_wronly_creat_excl(self):
+self.vFile_test(write=True, creat=True, excl=True)
+
+def test_platform_file_wronly_fail(self):
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+# create a temporary directory
+with tempfile.TemporaryDirectory() as temp_dir:
+temp_path = os.path.join(temp_dir, "test")
+self.assertFalse(os.path.exists(temp_path))
+
+# attempt to open the file without O_CREAT
+self.do_handshake()
+self.test_sequence.add_log_lines(
+["read packet: $vFile:open:%s,1,0#00" % (
+binascii.b2a_hex(temp_path.encode()).decode(),),
+ {"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def test_platform_file_wronly_creat_excl_fail(self):
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+with tempfile.NamedTemporaryFile() as temp_file:
+# attempt to open the file with O_CREAT|O_EXCL
+self.do_handshake()
+self.test_sequence.add_log_lines(
+["read packet: $vFile:open:%s,a01,0#00" % (
+binascii.b2a_hex(temp_file.name.encode()).decode(),),
+ {"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def expect_error(self):
+self.test_sequence.add_log_lines(
+[{"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def vFile_test(self, read=False, write=False, append=False, trunc=False,
+   creat=False, excl=False):
+if read and write:
+mode = 2
+elif write:
+mode = 1
+else:  # read
+mode = 0
+if append:
+mode |= 8
+if creat:
+mode |= 0x200
+if trunc:
+mode |= 0x400
+if excl:
+mode |= 0x800
+
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+# create a temporary file with some data
+test_data = 'some test data longer than 16 bytes\n'
+if creat:
+temp_dir = tempfile.TemporaryDirectory()
+else:
+temp_file = tempfile.NamedTemporaryFile()
+
+try:
+if creat:
+temp_path = os.path.join(temp_dir.name, "test")
+self.assertFalse(os.path.exists(temp_path))
+else:
+temp_file.write(test_data.encode())
+temp_file.flush()
+temp_path = temp_file.name
+
+# open the file for reading
+self.do_handshake()
+s

[Lldb-commits] [lldb] 825a08f - [lldb] Fix TestFunctionStarts.py on AS

2021-08-06 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-08-06T09:03:01-07:00
New Revision: 825a08f898f0eb727408e67fb75acc1ebdc1b85b

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

LOG: [lldb] Fix TestFunctionStarts.py on AS

The tests strips the binary which invalidates the code signature. Skip
code signing for this test.

Added: 


Modified: 
lldb/test/API/macosx/function-starts/TestFunctionStarts.py

Removed: 




diff  --git a/lldb/test/API/macosx/function-starts/TestFunctionStarts.py 
b/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
index 5dc43a5a10935..e8f540b5a5fc7 100644
--- a/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ b/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -22,7 +22,7 @@ class FunctionStartsTestCase(TestBase):
 @skipIfReproducer # File synchronization is not supported during replay.
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
-self.build()
+self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
 self.do_function_starts(False)
 
 @skipIfRemote
@@ -30,7 +30,7 @@ def test_function_starts_binary(self):
 @skipIfReproducer # File synchronization is not supported during replay.
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
-self.build()
+self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
 self.do_function_starts(True)
 
 def do_function_starts(self, in_memory):



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


[Lldb-commits] [PATCH] D107659: [nfc] [lldb] Assertions for D106270 - [DWARF5] Fix offset check when using .debug_names

2021-08-06 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil created this revision.
jankratochvil added reviewers: kimanh, labath, clayborg.
jankratochvil added a project: LLDB.
Herald added subscribers: JDevlieghere, arphaman.
jankratochvil requested review of this revision.

As this issue is a bit difficult to debug it is better to make it safe against 
future changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107659

Files:
  lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
  lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
  lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
  lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
  lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp

Index: lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
===
--- lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
+++ lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
@@ -31,12 +31,15 @@
 // the compile unit using the name index if it is split.
 // RUN: %clang -c -o %t-1.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %s
 // RUN: %clang -c -o %t-2.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %S/Inputs/find-variable-file-2.cpp
-// RUN: ld.lld %t-1.o %t-2.o -o %t
+// RUN: %clang -c -o %t-3.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %S/Inputs/find-variable-file-3.cpp
+// RUN: ld.lld %t-1.o %t-2.o %t-3.o -o %t
 // RUN: llvm-readobj --sections %t | FileCheck %s --check-prefix NAMES
 // RUN: lldb-test symbols --file=find-variable-file.cpp --find=variable %t | \
 // RUN:   FileCheck --check-prefix=ONE %s
 // RUN: lldb-test symbols --file=find-variable-file-2.cpp --find=variable %t | \
 // RUN:   FileCheck --check-prefix=TWO %s
+// RUN: lldb-test symbols --file=find-variable-file-3.cpp --find=variable \
+// RUN:   --name=notexists %t
 
 // NAMES: Name: .debug_names
 
Index: lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
@@ -0,0 +1,2 @@
+// No variable should exist in this file.
+void f() {}
Index: lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
+++ lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
@@ -38,8 +38,9 @@
   bool Find(const lldb_private::RegularExpression ®ex,
 llvm::function_ref callback) const;
 
+  /// \a unit must be from GetNonSkeletonUnit().
   void
-  FindAllEntriesForUnit(const DWARFUnit &unit,
+  FindAllEntriesForUnit(DWARFUnit &unit,
 llvm::function_ref callback) const;
 
   void
Index: lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
@@ -45,8 +45,8 @@
 }
 
 void NameToDIE::FindAllEntriesForUnit(
-const DWARFUnit &unit,
-llvm::function_ref callback) const {
+DWARFUnit &unit, llvm::function_ref callback) const {
+  lldbassert(&unit == &unit.GetNonSkeletonUnit());
   const uint32_t size = m_map.GetSize();
   for (uint32_t i = 0; i < size; ++i) {
 const DIERef &die_ref = m_map.GetValueAtIndexUnchecked(i);
Index: lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -359,6 +359,7 @@
 
 void ManualDWARFIndex::GetGlobalVariables(
 DWARFUnit &unit, llvm::function_ref callback) {
+  lldbassert(!unit.GetSymbolFileDWARF().GetDwoNum());
   Index();
   m_set.globals.FindAllEntriesForUnit(unit.GetNonSkeletonUnit(),
   DIERefCallback(callback));
Index: lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -124,6 +124,7 @@
 
 void DebugNamesDWARFIndex::GetGlobalVariables(
 DWARFUnit &cu, llvm::function_ref callback) {
+  lldbassert(!cu.GetSymbolFileDWARF().GetDwoNum());
   uint64_t cu_offset = cu.GetOffset();
   bool found_entry_for_cu = false;
   for (const DebugNames::NameIndex &ni: *m_debug_names_up) {
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
@@

[Lldb-commits] [PATCH] D106270: [DWARF5] Fix offset check when using .debug_names

2021-08-06 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil accepted this revision.
jankratochvil added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp:34
+// RUN: %clang -c -o %t-2.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf 
-gpubnames %S/Inputs/find-variable-file-2.cpp
+// RUN: ld.lld %t-1.o %t-2.o -o %t
+// RUN: llvm-readobj --sections %t | FileCheck %s --check-prefix NAMES

I see `ld.lld` is being run directly even in other testcases so OK.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106270

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


[Lldb-commits] [PATCH] D105182: [lldb] Add "memory tag write" command

2021-08-06 Thread Jessica Clarke via Phabricator via lldb-commits
jrtc27 added a comment.

In D105182#2930795 , @DavidSpickett 
wrote:

>> Many different types of memory tagging exist, MTE is but one.
>
> Sure. I'm not opposed to making changes to adapt to the properties of 
> different tags. However the most concrete one I have access to it MTE so that 
> has shaped the initial support and assumptions.
>
>> CHERI uses memory tagging for something completely different (tracking valid 
>> capability, ie pointer provenance), and its tags make sense to read (though 
>> are a property of the stored data, not the memory allocation), but not 
>> explicitly write (only implicitly by writing a capability to the associated 
>> location, which will include the non-addressable tag bit), as that is 
>> architecturally forbidden in order to ensure that the hardware-enforced tags 
>> can never be corrupted by software.
>
> Definitely we could add properties to the tagging scheme information to 
> disable the read and/or/write commands. Something like:
>
>   (lldb) memory tag write 0x12341234 23
>   Error: Cannot write memory tags for address 0x12341234.  tags are not 
> writeable by user software
>
> If you mean hiding the commands completely from the interactive sessions, 
> there's no existing mechanism for it but you could make the argument for it. 
> The current pattern is to show the command but error saying that it is 
> unsupported. (this also happens when a remote doesn't support some feature)

Yeah that kind of UI thing isn't really my concern.

>> Moreover, in future, CHERI and MTE will be composed (there is ongoing 
>> experimental work to investigate doing so on CHERI-RISC-V, and if Arm's 
>> experimental Morello prototype is adopted in a future version of the Arm 
>> architecture it will also have to compose with MTE). See also the core dump 
>> format for MTE tags, which specifies the _type_ of tag, specifically to 
>> accommodate other uses of tagged memory.
>
> Certainly. There's nothing stopping us supporting such a configuration apart 
> from (at least personally) zero experience or way to test such a thing. 
> Something like:
>
>   (lldb) memory read foo
>   Error: Current process has multiple memory tag types. "foo", "bar". Please 
> select one with the --type argument.
>
> It's not something I could really implement with just MTE as the vast 
> majority of the code would be untested but with a use case we could 
> definitely make the changes.

My concern with that would just be that, if MTE is all that most users have 
accesses to for a while, various things will be written assuming `memory tag` 
means MTE and that if they run it on an MTE-less CHERI system it will do 
surprising things and they'll get confused. But maybe that doesn't matter and 
the benefit of having a shorter command when you only have one tag type 
outweighs that (though, LLDB is no stranger to verbose commands!).

> Where this does become more thorny is the lldb API where we have more 
> stringent commitments to not changing it. Happily, I haven't started on this 
> yet and your concerns very much need to be included.

Yes, I do think it's important that the API always be explicit in what type of 
tag is used, presumably with an initially single-member enum.

> Perhaps you could write up something and post it to the lldb-dev list for 
> more visibility? I'd be interested to know how things work in the existing 
> lldb cheri port (I assume there is one, there is for Morello at least).

I'll see if I can manage that over the weekend. FWIW, there is no CHERI LLDB, 
only a Morello LLDB, as our resident debugger expert is familiar with, and 
contributes to, GDB (and that's what we're also more familiar with using), 
though we have talked about wanting one. We don't currently have support for 
reading tagged memory in CHERI GDB, and I don't think Arm's Morello LLDB does 
currently either, they're both fairly limited in their functionality as we have 
other more pressing things to be working on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105182

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: friss, jingham.
JDevlieghere requested review of this revision.

Upstream support for NSConstantArray, NSConstantIntegerNumber, 
NSConstant{Float,Double}Number and NSConstantDictionary. We would've upstreamed 
this earlier but testing it requires `-fno-constant-nsnumber-literals`, 
`-fno-constant-nsarray-literals` and `-fno-constant-nsdictionary-literals` 
which haven't been upstreamed yet. As a temporary workaround use the system 
compiler (`xcrun clang`) for the constant variant of the tests.

I'm just upstreaming this. The patch and the tests were all authored by Fred 
Riss.


https://reviews.llvm.org/D107660

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  lldb/source/Plugins/Language/ObjC/NSArray.cpp
  lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
  lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
  
lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py
  lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
  lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
  lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
  
lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Index: lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
===
--- lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
+++ lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
@@ -21,9 +21,27 @@
 # Find the line number to break inside main().
 self.line = line_number('main.m', '// break here')
 
+@skipUnlessDarwin
 @expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
 def test_single_entry_dict(self):
 self.build()
+self.run_tests()
+
+@skipUnlessDarwin
+@expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
+def test_single_entry_dict_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+def run_tests(self):
 exe = self.getBuildArtifact("a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
Index: lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
===
--- lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
+++ lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
@@ -8,6 +8,22 @@
 
   def test_ordered_set(self):
 self.build()
+self.run_tests()
+
+  @skipUnlessDarwin
+  def test_ordered_set_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+  def run_tests(self):
 src_file = "main.m"
 src_file_spec = lldb.SBFileSpec(src_file)
 (target, process, thread, main_breakpoint) = lldbutil.run_to_source_breakpoint(self,
Index: lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
===
--- lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
+++ lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
@@ -20,6 +20,20 @@
   

[Lldb-commits] [PATCH] D107659: [nfc] [lldb] Assertions for D106270 - [DWARF5] Fix offset check when using .debug_names

2021-08-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Can we not just grab the skeleton unit when/if needed instead of asserting in 
many places?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107659

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


[Lldb-commits] [PATCH] D107659: [nfc] [lldb] Assertions for D106270 - [DWARF5] Fix offset check when using .debug_names

2021-08-06 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil updated this revision to Diff 364861.
jankratochvil added a comment.

In D107659#2931836 , @clayborg wrote:

> Can we not just grab the skeleton unit when/if needed instead of asserting in 
> many places?

I agree it could be unified for API simplicity to be always the skeleton unit, 
thanks for the idea. Done in this patch. Still I believe it should be asserted 
as unfortunately with the current Unit types it cannot be compile-time checked.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107659

Files:
  lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.h
  lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
  lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
  lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
  lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp

Index: lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
===
--- lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
+++ lldb/test/Shell/SymbolFile/DWARF/x86/find-variable-file.cpp
@@ -31,12 +31,15 @@
 // the compile unit using the name index if it is split.
 // RUN: %clang -c -o %t-1.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %s
 // RUN: %clang -c -o %t-2.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %S/Inputs/find-variable-file-2.cpp
-// RUN: ld.lld %t-1.o %t-2.o -o %t
+// RUN: %clang -c -o %t-3.o --target=x86_64-pc-linux -gdwarf-5 -gsplit-dwarf -gpubnames %S/Inputs/find-variable-file-3.cpp
+// RUN: ld.lld %t-1.o %t-2.o %t-3.o -o %t
 // RUN: llvm-readobj --sections %t | FileCheck %s --check-prefix NAMES
 // RUN: lldb-test symbols --file=find-variable-file.cpp --find=variable %t | \
 // RUN:   FileCheck --check-prefix=ONE %s
 // RUN: lldb-test symbols --file=find-variable-file-2.cpp --find=variable %t | \
 // RUN:   FileCheck --check-prefix=TWO %s
+// RUN: lldb-test symbols --file=find-variable-file-3.cpp --find=variable \
+// RUN:   --name=notexists %t
 
 // NAMES: Name: .debug_names
 
Index: lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/x86/Inputs/find-variable-file-3.cpp
@@ -0,0 +1,2 @@
+// No variable should exist in this file.
+void f() {}
Index: lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
+++ lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.h
@@ -38,8 +38,9 @@
   bool Find(const lldb_private::RegularExpression ®ex,
 llvm::function_ref callback) const;
 
+  /// \a unit must be the skeleton unit if possible, not GetNonSkeletonUnit().
   void
-  FindAllEntriesForUnit(const DWARFUnit &unit,
+  FindAllEntriesForUnit(DWARFUnit &unit,
 llvm::function_ref callback) const;
 
   void
Index: lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
@@ -45,15 +45,16 @@
 }
 
 void NameToDIE::FindAllEntriesForUnit(
-const DWARFUnit &unit,
-llvm::function_ref callback) const {
+DWARFUnit &s_unit, llvm::function_ref callback) const {
+  lldbassert(!s_unit.GetSymbolFileDWARF().GetDwoNum());
+  const DWARFUnit &ns_unit = s_unit.GetNonSkeletonUnit();
   const uint32_t size = m_map.GetSize();
   for (uint32_t i = 0; i < size; ++i) {
 const DIERef &die_ref = m_map.GetValueAtIndexUnchecked(i);
-if (unit.GetSymbolFileDWARF().GetDwoNum() == die_ref.dwo_num() &&
-unit.GetDebugSection() == die_ref.section() &&
-unit.GetOffset() <= die_ref.die_offset() &&
-die_ref.die_offset() < unit.GetNextUnitOffset()) {
+if (ns_unit.GetSymbolFileDWARF().GetDwoNum() == die_ref.dwo_num() &&
+ns_unit.GetDebugSection() == die_ref.section() &&
+ns_unit.GetOffset() <= die_ref.die_offset() &&
+die_ref.die_offset() < ns_unit.GetNextUnitOffset()) {
   if (!callback(die_ref))
 return;
 }
Index: lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -359,9 +359,9 @@
 
 void ManualDWARFIndex::GetGlobalVariables(
 DWARFUnit &unit, llvm::function_ref callback) {
+  lldbassert(!unit.GetSymbolFileDWARF().GetDwoNum());
   Index();
-  m_set.globals.FindAllEntriesForUnit(unit.GetNonSkeletonUni

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

Just a few little nits.




Comment at: lldb/source/Plugins/Language/ObjC/Cocoa.cpp:509
+float flt_value = 0.0f;
+memcpy(&flt_value, &flt_as_int, sizeof(flt_as_int));
+NSNumber_FormatFloat(valobj, stream, flt_value, options.GetLanguage());

Shouldn't this be done with a DataExtractor?  The code is assuming that you can 
get a valid host float by pasting target bytes into a host float.  While most 
likely everybody is using the same float & double representations these days, 
that doesn't seem like something we should rely on.



Comment at: lldb/source/Plugins/Language/ObjC/NSDictionary.cpp:908-913
+  m_keys_ptr = process_sp->ReadUnsignedIntegerFromMemory(
+  valobj_addr + 3 * m_ptr_size, m_ptr_size, 0, error);
+  if (error.Fail())
+return false;
+  m_objects_ptr = process_sp->ReadUnsignedIntegerFromMemory(
+  valobj_addr + 4 * m_ptr_size, m_ptr_size, 0, error);

These are pointers, shouldn't we be using ReadPointerFromMemory?


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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 364869.
JDevlieghere marked 2 inline comments as done.
JDevlieghere added a comment.

- Use `ReadPointerFromMemory`


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

https://reviews.llvm.org/D107660

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  lldb/source/Plugins/Language/ObjC/NSArray.cpp
  lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
  lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
  
lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py
  lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
  lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
  lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
  
lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Index: lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
===
--- lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
+++ lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
@@ -21,9 +21,27 @@
 # Find the line number to break inside main().
 self.line = line_number('main.m', '// break here')
 
+@skipUnlessDarwin
 @expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
 def test_single_entry_dict(self):
 self.build()
+self.run_tests()
+
+@skipUnlessDarwin
+@expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
+def test_single_entry_dict_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+def run_tests(self):
 exe = self.getBuildArtifact("a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
Index: lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
===
--- lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
+++ lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
@@ -8,6 +8,22 @@
 
   def test_ordered_set(self):
 self.build()
+self.run_tests()
+
+  @skipUnlessDarwin
+  def test_ordered_set_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+  def run_tests(self):
 src_file = "main.m"
 src_file_spec = lldb.SBFileSpec(src_file)
 (target, process, thread, main_breakpoint) = lldbutil.run_to_source_breakpoint(self,
Index: lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
===
--- lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
+++ lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
@@ -20,6 +20,20 @@
 self.build()
 self.printarray_data_formatter_commands()
 
+@skipUnlessDarwin
+def test_print_array_no_const(self):
+"""Test that expr -O -Z works"""
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-n

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added inline comments.



Comment at: lldb/source/Plugins/Language/ObjC/Cocoa.cpp:509
+float flt_value = 0.0f;
+memcpy(&flt_value, &flt_as_int, sizeof(flt_as_int));
+NSNumber_FormatFloat(valobj, stream, flt_value, options.GetLanguage());

jingham wrote:
> Shouldn't this be done with a DataExtractor?  The code is assuming that you 
> can get a valid host float by pasting target bytes into a host float.  While 
> most likely everybody is using the same float & double representations these 
> days, that doesn't seem like something we should rely on.
This seems pretty common across the existing code. I agree we should fix that, 
but probably as a follow-up patch that fixes this across the whole file.


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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107664: [lldb] [Commands] Remove 'append' from 'platform file open' mode

2021-08-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: labath, emaste, krytarowski, jasonmolenda, 
JDevlieghere, clayborg.
mgorny requested review of this revision.

Remove File::eOpenOptionAppend from the mode used by 'platform file
open' command.  According to POSIX, O_APPEND causes all successive
writes to be done at the end of the file.  This effectively makes
the offset argument to 'platform file write' meaningless.

Furthermore, apparently O_APPEND is not implemented reliably everywhere.
The Linux manpage for pwrite(2) suggests that Linux does not respect
O_APPEND there, so the actual behavior would be dependent on how
the vFile:pwrite packet is implemented on the server.

Ideally, the mode used for opening flags would be provided via options.
However, changing the default mode seems to be a reasonable intermediate
solution.


https://reviews.llvm.org/D107664

Files:
  lldb/source/Commands/CommandObjectPlatform.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py


Index: 
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -34,7 +34,7 @@
 self.match("platform file close 16",
[r"file 16 closed."])
 self.assertPacketLogContains([
-"vFile:open:2f736f6d652f66696c652e747874,020a,01ed",
+"vFile:open:2f736f6d652f66696c652e747874,0202,01ed",
 "vFile:pread:10,d,b",
 "vFile:pwrite:10,b,teststring",
 "vFile:close:10",
@@ -69,7 +69,7 @@
[r"error: Invalid argument"],
error=True)
 self.assertPacketLogContains([
-"vFile:open:2f736f6d652f66696c652e747874,020a,01ed",
+"vFile:open:2f736f6d652f66696c652e747874,0202,01ed",
 "vFile:pread:10,d,b",
 "vFile:pwrite:10,b,teststring",
 "vFile:close:10",
Index: lldb/source/Commands/CommandObjectPlatform.cpp
===
--- lldb/source/Commands/CommandObjectPlatform.cpp
+++ lldb/source/Commands/CommandObjectPlatform.cpp
@@ -498,8 +498,7 @@
 lldb::eFilePermissionsWorldRead;
   lldb::user_id_t fd = platform_sp->OpenFile(
   FileSpec(cmd_line),
-  File::eOpenOptionReadWrite | File::eOpenOptionAppend |
-   File::eOpenOptionCanCreate,
+  File::eOpenOptionReadWrite | File::eOpenOptionCanCreate,
   perms, error);
   if (error.Success()) {
 result.AppendMessageWithFormat("File Descriptor = %" PRIu64 "\n", fd);


Index: lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -34,7 +34,7 @@
 self.match("platform file close 16",
[r"file 16 closed."])
 self.assertPacketLogContains([
-"vFile:open:2f736f6d652f66696c652e747874,020a,01ed",
+"vFile:open:2f736f6d652f66696c652e747874,0202,01ed",
 "vFile:pread:10,d,b",
 "vFile:pwrite:10,b,teststring",
 "vFile:close:10",
@@ -69,7 +69,7 @@
[r"error: Invalid argument"],
error=True)
 self.assertPacketLogContains([
-"vFile:open:2f736f6d652f66696c652e747874,020a,01ed",
+"vFile:open:2f736f6d652f66696c652e747874,0202,01ed",
 "vFile:pread:10,d,b",
 "vFile:pwrite:10,b,teststring",
 "vFile:close:10",
Index: lldb/source/Commands/CommandObjectPlatform.cpp
===
--- lldb/source/Commands/CommandObjectPlatform.cpp
+++ lldb/source/Commands/CommandObjectPlatform.cpp
@@ -498,8 +498,7 @@
 lldb::eFilePermissionsWorldRead;
   lldb::user_id_t fd = platform_sp->OpenFile(
   FileSpec(cmd_line),
-  File::eOpenOptionReadWrite | File::eOpenOptionAppend |
-   File::eOpenOptionCanCreate,
+  File::eOpenOptionReadWrite | File::eOpenOptionCanCreate,
   perms, error);
   if (error.Success()) {
 result.AppendMessageWithFormat("File Descriptor = %" PRIu64 "\n", fd);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D107475: [lldb] [gdb-remote] Use hexadecimal numbers in vFile packets for GDB compliance

2021-08-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 364873.
mgorny added a comment.

Fix `vFile:pread` to actually return the underlying error in client.


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

https://reviews.llvm.org/D107475

Files:
  lldb/docs/lldb-platform-packets.txt
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
  lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py

Index: lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/TestGdbRemotePlatformFile.py
@@ -0,0 +1,215 @@
+from __future__ import print_function
+
+# lldb test suite imports
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import TestBase
+
+# gdb-remote-specific imports
+import lldbgdbserverutils
+from gdbremote_testcase import GdbRemoteTestCaseBase
+
+import binascii
+import stat
+import tempfile
+
+
+class TestGdbRemotePlatformFile(GdbRemoteTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_platform_file_rdonly(self):
+self.vFile_test(read=True)
+
+def test_platform_file_wronly(self):
+self.vFile_test(write=True)
+
+def test_platform_file_rdwr(self):
+self.vFile_test(read=True, write=True)
+
+def test_platform_file_wronly_append(self):
+self.vFile_test(write=True, append=True)
+
+def test_platform_file_rdwr_append(self):
+self.vFile_test(read=True, write=True, append=True)
+
+def test_platform_file_wronly_trunc(self):
+self.vFile_test(write=True, trunc=True)
+
+def test_platform_file_rdwr_trunc(self):
+self.vFile_test(read=True, write=True, trunc=True)
+
+def test_platform_file_wronly_creat(self):
+self.vFile_test(write=True, creat=True)
+
+def test_platform_file_wronly_creat_excl(self):
+self.vFile_test(write=True, creat=True, excl=True)
+
+def test_platform_file_wronly_fail(self):
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+# create a temporary directory
+with tempfile.TemporaryDirectory() as temp_dir:
+temp_path = os.path.join(temp_dir, "test")
+self.assertFalse(os.path.exists(temp_path))
+
+# attempt to open the file without O_CREAT
+self.do_handshake()
+self.test_sequence.add_log_lines(
+["read packet: $vFile:open:%s,1,0#00" % (
+binascii.b2a_hex(temp_path.encode()).decode(),),
+ {"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def test_platform_file_wronly_creat_excl_fail(self):
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+with tempfile.NamedTemporaryFile() as temp_file:
+# attempt to open the file with O_CREAT|O_EXCL
+self.do_handshake()
+self.test_sequence.add_log_lines(
+["read packet: $vFile:open:%s,a01,0#00" % (
+binascii.b2a_hex(temp_file.name.encode()).decode(),),
+ {"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def expect_error(self):
+self.test_sequence.add_log_lines(
+[{"direction": "send",
+ "regex": r"^\$F-1,[0-9a-fA-F]+#[0-9a-fA-F]{2}$"}],
+True)
+self.expect_gdbremote_sequence()
+
+def vFile_test(self, read=False, write=False, append=False, trunc=False,
+   creat=False, excl=False):
+if read and write:
+mode = 2
+elif write:
+mode = 1
+else:  # read
+mode = 0
+if append:
+mode |= 8
+if creat:
+mode |= 0x200
+if trunc:
+mode |= 0x400
+if excl:
+mode |= 0x800
+
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+
+# create a temporary file with some data
+test_data = 'some test data longer than 16 bytes\n'
+if creat:
+temp_dir = tempfile.TemporaryDirectory()
+else:
+temp_file = tempfile.NamedTemporaryFile()
+
+try:
+if creat:
+temp_path = os.path.join(temp_dir.name, "test")
+self.assertFalse(os.path.exists(temp_path))
+else:
+temp_file.write(test_data.encode())
+temp_file.flush()
+temp_path = temp_file.name
+
+# open the file for reading
+self.do_handshake(

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

If the float/double pattern wasn't introduced here, then it's fine by me to fix 
it in a follow-on patch.
Otherwise, LGTM.


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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107665: [lldb] [Commands] Fix reporting errors in 'platform file read/write'

2021-08-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: labath, emaste, krytarowski, jasonmolenda, clayborg, 
JDevlieghere.
mgorny requested review of this revision.

Fix 'platform file read' and 'platform file write' commands to correctly
detect erraneous return and report it as such.  Currently, errors were
implicitly printed as a return value of -1, and the commands were
assumed to be successful.


https://reviews.llvm.org/D107665

Files:
  lldb/source/Commands/CommandObjectPlatform.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py


Index: 
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -60,11 +60,12 @@
 self.match("platform file open /some/file.txt -v 0755",
[r"error: Invalid argument"],
error=True)
-# TODO: fix the commands to fail on unsuccessful result
 self.match("platform file read 16 -o 11 -c 13",
-   [r"Return = -1\nData = \"\""])
+   [r"error: Invalid argument"],
+   error=True)
 self.match("platform file write 16 -o 11 -d teststring",
-   [r"Return = -1"])
+   [r"error: Invalid argument"],
+   error=True)
 self.match("platform file close 16",
[r"error: Invalid argument"],
error=True)
Index: lldb/source/Commands/CommandObjectPlatform.cpp
===
--- lldb/source/Commands/CommandObjectPlatform.cpp
+++ lldb/source/Commands/CommandObjectPlatform.cpp
@@ -588,11 +588,15 @@
   }
   std::string buffer(m_options.m_count, 0);
   Status error;
-  uint32_t retcode = platform_sp->ReadFile(
+  uint64_t retcode = platform_sp->ReadFile(
   fd, m_options.m_offset, &buffer[0], m_options.m_count, error);
-  result.AppendMessageWithFormat("Return = %d\n", retcode);
-  result.AppendMessageWithFormat("Data = \"%s\"\n", buffer.c_str());
-  result.SetStatus(eReturnStatusSuccessFinishResult);
+  if (retcode != -1) {
+result.AppendMessageWithFormat("Return = %d\n", retcode);
+result.AppendMessageWithFormat("Data = \"%s\"\n", buffer.c_str());
+result.SetStatus(eReturnStatusSuccessFinishResult);
+  } else {
+result.AppendError(error.AsCString());
+  }
 } else {
   result.AppendError("no platform currently selected\n");
 }
@@ -677,11 +681,15 @@
   cmd_line);
 return result.Succeeded();
   }
-  uint32_t retcode =
+  uint64_t retcode =
   platform_sp->WriteFile(fd, m_options.m_offset, &m_options.m_data[0],
  m_options.m_data.size(), error);
-  result.AppendMessageWithFormat("Return = %d\n", retcode);
-  result.SetStatus(eReturnStatusSuccessFinishResult);
+  if (retcode != -1) {
+result.AppendMessageWithFormat("Return = %d\n", retcode);
+result.SetStatus(eReturnStatusSuccessFinishResult);
+  } else {
+result.AppendError(error.AsCString());
+  }
 } else {
   result.AppendError("no platform currently selected\n");
 }


Index: lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
@@ -60,11 +60,12 @@
 self.match("platform file open /some/file.txt -v 0755",
[r"error: Invalid argument"],
error=True)
-# TODO: fix the commands to fail on unsuccessful result
 self.match("platform file read 16 -o 11 -c 13",
-   [r"Return = -1\nData = \"\""])
+   [r"error: Invalid argument"],
+   error=True)
 self.match("platform file write 16 -o 11 -d teststring",
-   [r"Return = -1"])
+   [r"error: Invalid argument"],
+   error=True)
 self.match("platform file close 16",
[r"error: Invalid argument"],
error=True)
Index: lldb/source/Commands/CommandObjectPlatform.cpp
===
--- lldb/source/Commands/CommandObjectPlatform.cpp
+++ lldb/source/Commands/CommandObjectPlatform.cpp
@@ -588,11 +588,15 @@
   }
   std::string buffer(m_options.m_count, 0);
   Status error;
-  uint32_t retcode = platform_sp->R

[Lldb-commits] [lldb] 9ed7416 - [lldb] Try harder to find the __NSCFBoolean addresses

2021-08-06 Thread Jonas Devlieghere via lldb-commits

Author: Fred Riss
Date: 2021-08-06T13:04:29-07:00
New Revision: 9ed7416aaf257b13079b48f856df9b45d783fab2

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

LOG: [lldb] Try harder to find the __NSCFBoolean addresses

It looks like recent CoreFoundation builds strip the non-public symbol
that we were looking for to find the 2 boolean "classes". The public
symbol is of course there, and it contains the address of the private
one. If we don't find the private symbol directly, go through a memory
read at the public symbol's location instead.

Added: 


Modified: 

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index 10512a97ad69c..b4b6c8bf74861 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -2967,11 +2967,13 @@ bool AppleObjCRuntimeV2::GetCFBooleanValuesIfNeeded() {
   if (m_CFBoolean_values)
 return true;
 
-  static ConstString g_kCFBooleanFalse("__kCFBooleanFalse");
-  static ConstString g_kCFBooleanTrue("__kCFBooleanTrue");
+  static ConstString g___kCFBooleanFalse("__kCFBooleanFalse");
+  static ConstString g___kCFBooleanTrue("__kCFBooleanTrue");
+  static ConstString g_kCFBooleanFalse("kCFBooleanFalse");
+  static ConstString g_kCFBooleanTrue("kCFBooleanTrue");
 
-  std::function get_symbol =
-  [this](ConstString sym) -> lldb::addr_t {
+  std::function get_symbol =
+  [this](ConstString sym, ConstString real_sym) -> lldb::addr_t {
 SymbolContextList sc_list;
 GetProcess()->GetTarget().GetImages().FindSymbolsWithNameAndType(
 sym, lldb::eSymbolTypeData, sc_list);
@@ -2981,12 +2983,26 @@ bool AppleObjCRuntimeV2::GetCFBooleanValuesIfNeeded() {
   if (sc.symbol)
 return sc.symbol->GetLoadAddress(&GetProcess()->GetTarget());
 }
+GetProcess()->GetTarget().GetImages().FindSymbolsWithNameAndType(
+real_sym, lldb::eSymbolTypeData, sc_list);
+if (sc_list.GetSize() != 1)
+  return LLDB_INVALID_ADDRESS;
 
-return LLDB_INVALID_ADDRESS;
+SymbolContext sc;
+sc_list.GetContextAtIndex(0, sc);
+if (!sc.symbol)
+  return LLDB_INVALID_ADDRESS;
+
+lldb::addr_t addr = sc.symbol->GetLoadAddress(&GetProcess()->GetTarget());
+Status error;
+addr = GetProcess()->ReadPointerFromMemory(addr, error);
+if (error.Fail())
+  return LLDB_INVALID_ADDRESS;
+return addr;
   };
 
-  lldb::addr_t false_addr = get_symbol(g_kCFBooleanFalse);
-  lldb::addr_t true_addr = get_symbol(g_kCFBooleanTrue);
+  lldb::addr_t false_addr = get_symbol(g___kCFBooleanFalse, g_kCFBooleanFalse);
+  lldb::addr_t true_addr = get_symbol(g___kCFBooleanTrue, g_kCFBooleanTrue);
 
   return (m_CFBoolean_values = {false_addr, true_addr}).operator bool();
 }



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


[Lldb-commits] [PATCH] D107386: [LLDB][GUI] Add Breakpoints window

2021-08-06 Thread Omar Emara via Phabricator via lldb-commits
OmarEmaraDev added a comment.

@clayborg With you suggestions it currently looks like this. The concern I have 
is that lines are now 36 characters longer, and some important information are 
now truncated. The breakpoint and breakpoint locations IDs seems to be just the 
index of the objects in the tree, are they not? In this case, they seem 
redundant to me. Similarly, the address takes a lot of space and is included in 
the next level of details, so it might not be as important to include in this 
level either.

F18404076: 20210806-225259.png <https://reviews.llvm.org/F18404076>

I am having some difficulties adding the last level of details. My initial 
approach was to add and compute a StringList containing all the details to the 
BreakpointLocationTreeDelegate. Then I added a  StringTreeDelegate that have 
the string from the string list in its user data which  it then simply draws. 
The problem, I realized, is that the BreakpointLocationTreeDelegate is shared 
between all Breakpoint Location items, so the list is overwritten by different 
elements. What I did was instance multiple BreakpointLocationTreeDelegate for 
each item, but that tuned more involved that I thought, so I am not sure what 
the best approach would be now. What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107386

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


[Lldb-commits] [PATCH] D107669: Create "process trace save" command

2021-08-06 Thread hanbing wang via Phabricator via lldb-commits
hanbingwang created this revision.
hanbingwang added reviewers: wallace, clayborg.
Herald added subscribers: dang, mgorny.
hanbingwang requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

added new command "process trace save -d ".
-it only support Intel-pt right now.
-it saves a JSON file as /trace.json, with the main properties of 
the trace session.
-it saves binary Intel-PT trace as /thread_id.trace; each file saves 
each thread.

Example:
b main
run
process trace start
n
process trace save -d /tmp/mytrace
A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To 
load the trace that was just saved:
trace load /tmp/mytrace
thread trace dump instructions
You should see the instructions of the trace got printed.

To run a test:
./bin/lldb-dotest -p TestTraceSave


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107669

Files:
  lldb/include/lldb/Target/Trace.h
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Trace/common/CMakeLists.txt
  lldb/source/Plugins/Trace/common/TraceJSONStructs.cpp
  lldb/source/Plugins/Trace/common/TraceJSONStructs.h
  lldb/source/Plugins/Trace/common/TraceSessionFileParser.cpp
  lldb/source/Plugins/Trace/common/TraceSessionFileParser.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.h
  lldb/test/API/commands/trace/TestTraceSave.py

Index: lldb/test/API/commands/trace/TestTraceSave.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceSave.py
@@ -0,0 +1,70 @@
+import lldb
+from intelpt_testcase import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceSave(TraceIntelPTTestCaseBase):
+mydir = TestBase.compute_mydir(__file__)
+
+def testErrorMessages(self):
+# We first check the output when there are no targets
+self.expect("process trace save",
+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("process trace save",
+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("process trace save",
+substrs=["error: Process is not being traced"],
+error=True)
+
+def testSaveTrace(self):
+# Load a trace
+self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"),
+substrs=["intel-pt"])
+# Save the trace to 
+self.expect("process trace save -d " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir"))
+# Load the trace just saved
+self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir", "trace.json"),
+substrs=["intel-pt"])
+#dump instructions and check
+self.expect("thread trace dump instructions --raw --count 21 --forwards",
+substrs=['''thread #1: tid = 3842849
+[ 0] 0x00400511
+[ 1] 0x00400518
+[ 2] 0x0040051f
+[ 3] 0x00400529
+[ 4] 0x0040052d
+[ 5] 0x00400521
+[ 6] 0x00400525
+[ 7] 0x00400529
+[ 8] 0x0040052d
+[ 9] 0x00400521
+[10] 0x00400525
+[11] 0x00400529
+[12] 0x0040052d
+[13] 0x00400521
+[14] 0x00400525
+[15] 0x00400529
+[16] 0x0040052d
+[17] 0x00400521
+[18] 0x00400525
+[19] 0x00400529
+[20] 0x0040052d'''])
+
+#remove 
+shutil.rmtree(os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir"))
Index: lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.h

[Lldb-commits] [PATCH] D107669: [trace] [intel pt] Create a "process trace save" command

2021-08-06 Thread hanbing wang via Phabricator via lldb-commits
hanbingwang updated this revision to Diff 364893.
hanbingwang added a comment.

fix a typo. change a string "the trace of ..." from "the trace or ..."


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

https://reviews.llvm.org/D107669

Files:
  lldb/include/lldb/Target/Trace.h
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Trace/common/CMakeLists.txt
  lldb/source/Plugins/Trace/common/TraceJSONStructs.cpp
  lldb/source/Plugins/Trace/common/TraceJSONStructs.h
  lldb/source/Plugins/Trace/common/TraceSessionFileParser.cpp
  lldb/source/Plugins/Trace/common/TraceSessionFileParser.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.h
  lldb/test/API/commands/trace/TestTraceSave.py

Index: lldb/test/API/commands/trace/TestTraceSave.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceSave.py
@@ -0,0 +1,70 @@
+import lldb
+from intelpt_testcase import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceSave(TraceIntelPTTestCaseBase):
+mydir = TestBase.compute_mydir(__file__)
+
+def testErrorMessages(self):
+# We first check the output when there are no targets
+self.expect("process trace save",
+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("process trace save",
+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("process trace save",
+substrs=["error: Process is not being traced"],
+error=True)
+
+def testSaveTrace(self):
+# Load a trace
+self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"),
+substrs=["intel-pt"])
+# Save the trace to 
+self.expect("process trace save -d " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir"))
+# Load the trace just saved
+self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir", "trace.json"),
+substrs=["intel-pt"])
+#dump instructions and check
+self.expect("thread trace dump instructions --raw --count 21 --forwards",
+substrs=['''thread #1: tid = 3842849
+[ 0] 0x00400511
+[ 1] 0x00400518
+[ 2] 0x0040051f
+[ 3] 0x00400529
+[ 4] 0x0040052d
+[ 5] 0x00400521
+[ 6] 0x00400525
+[ 7] 0x00400529
+[ 8] 0x0040052d
+[ 9] 0x00400521
+[10] 0x00400525
+[11] 0x00400529
+[12] 0x0040052d
+[13] 0x00400521
+[14] 0x00400525
+[15] 0x00400529
+[16] 0x0040052d
+[17] 0x00400521
+[18] 0x00400525
+[19] 0x00400529
+[20] 0x0040052d'''])
+
+#remove 
+shutil.rmtree(os.path.join(self.getSourceDir(), "intelpt-trace", "trace_copy_dir"))
Index: lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.h
===
--- /dev/null
+++ lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileSaver.h
@@ -0,0 +1,124 @@
+//===-- TraceIntelPTSessionFileSaver.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_SOURCE_PLUGINS_TRACE_INTEL_PT_TRACEINTELPTSESSIONFILESAVER_H
+#define LLDB_SOURCE_PLUGINS_TRACE_INTEL_PT_TRACEINTELPTSESSIONFILESAVER_H
+
+#i

[Lldb-commits] [PATCH] D107386: [LLDB][GUI] Add Breakpoints window

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

In D107386#2932037 <https://reviews.llvm.org/D107386#2932037>, @OmarEmaraDev 
wrote:

> @clayborg With you suggestions it currently looks like this. The concern I 
> have is that lines are now 36 characters longer, and some important 
> information are now truncated. The breakpoint and breakpoint locations IDs 
> seems to be just the index of the objects in the tree, are they not? In this 
> case, they seem redundant to me.

The breakpoint ID & loc ID are how you would refer to the breakpoint or 
location in any console commands, and also to go from the breakpoint ID 
displayed in a stop notification back to the entry in the breakpoints list.  
Those end up being fairly common operations.

You also can't just count nodes to figure out the breakpoint ID from the tree, 
since we don't fill in holes in the numbering when you delete a breakpoint.

I don't have a strong opinion about the addresses, but I think you do need the 
breakpoint & location ID's in the UI somewhere.

> Similarly, the address takes a lot of space and is included in the next level 
> of details, so it might not be as important to include in this level either.
>
> F18404076: 20210806-225259.png <https://reviews.llvm.org/F18404076>
>
> I am having some difficulties adding the last level of details. My initial 
> approach was to add and compute a StringList containing all the details to 
> the BreakpointLocationTreeDelegate. Then I added a  StringTreeDelegate that 
> have the string from the string list in its user data which  it then simply 
> draws. The problem, I realized, is that the BreakpointLocationTreeDelegate is 
> shared between all Breakpoint Location items, so the list is overwritten by 
> different elements. What I did was instance multiple 
> BreakpointLocationTreeDelegate for each item, but that tuned more involved 
> that I thought, so I am not sure what the best approach would be now. What do 
> you think?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107386

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


[Lldb-commits] [lldb] f362b05 - Add a "current" token to the ThreadID option to break set/modify.

2021-08-06 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2021-08-06T15:29:55-07:00
New Revision: f362b05d0dcd176348f19a63f8b7f4d4c0498bba

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

LOG: Add a "current" token to the ThreadID option to break set/modify.

This provides a convenient way to limit a breakpoint
to the current thread when setting it from the command line w/o
having to figure out what the current thread is.

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

Added: 


Modified: 
lldb/source/Commands/CommandObjectBreakpoint.cpp
lldb/source/Commands/Options.td

lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectBreakpoint.cpp 
b/lldb/source/Commands/CommandObjectBreakpoint.cpp
index 722d5c4d8f47..3f88a2fa6378 100644
--- a/lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ b/lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -110,7 +110,19 @@ class lldb_private::BreakpointOptionGroup : public 
OptionGroup {
 case 't': {
   lldb::tid_t thread_id = LLDB_INVALID_THREAD_ID;
   if (option_arg[0] != '\0') {
-if (option_arg.getAsInteger(0, thread_id))
+if (option_arg == "current") {
+  if (!execution_context) {
+error.SetErrorStringWithFormat("No context to determine current "
+   "thread");
+  } else {
+ThreadSP ctx_thread_sp = execution_context->GetThreadSP();
+if (!ctx_thread_sp || !ctx_thread_sp->IsValid()) {
+  error.SetErrorStringWithFormat("No currently selected thread");
+} else {
+  thread_id = ctx_thread_sp->GetID();
+}
+  }
+} else if (option_arg.getAsInteger(0, thread_id))
   error.SetErrorStringWithFormat("invalid thread id string '%s'",
  option_arg.str().c_str());
   }

diff  --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 6abb4788bed0..b78fb37f56c4 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -73,7 +73,7 @@ let Command = "breakpoint modify" in {
 "index matches this argument.">;
   def breakpoint_modify_thread_id : Option<"thread-id", "t">, Group<1>,
 Arg<"ThreadID">, Desc<"The breakpoint stops only for the thread whose TID "
-"matches this argument.">;
+"matches this argument.  The token 'current' resolves to the current 
thread's ID.">;
   def breakpoint_modify_thread_name : Option<"thread-name", "T">, Group<1>,
 Arg<"ThreadName">, Desc<"The breakpoint stops only for the thread whose "
 "thread name matches this argument.">;

diff  --git 
a/lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
 
b/lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
index e5505e1943ce..a8fa0a58e4d5 100644
--- 
a/lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
+++ 
b/lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
@@ -9,11 +9,15 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
-def set_thread_id(thread, breakpoint):
+def using_current(test, thread, breakpoint):
+bp_id = breakpoint.GetID()
+test.runCmd("break modify -t current {0}".format(bp_id))
+
+def set_thread_id(test, thread, breakpoint):
 id = thread.id
 breakpoint.SetThreadID(id)
 
-def set_thread_name(thread, breakpoint):
+def set_thread_name(test, thread, breakpoint):
 breakpoint.SetThreadName("main-thread")
 
 class ThreadSpecificBreakTestCase(TestBase):
@@ -32,6 +36,10 @@ def test_thread_id(self):
 def test_thread_name(self):
 self.do_test(set_thread_name)
 
+@expectedFailureAll(oslist=['ios', 'watchos', 'tvos', 'bridgeos'], 
archs=['armv7', 'armv7k'], bugnumber='rdar://problem/34563920') # armv7 ios 
problem - breakpoint with tid qualifier isn't working
+def test_current_token(self):
+self.do_test(using_current)
+
 def do_test(self, setter_method):
 """Test that we obey thread conditioned breakpoints."""
 self.build()
@@ -51,7 +59,7 @@ def do_test(self, setter_method):
 # thread joins the secondary thread, and then the main thread will
 # execute the code at the breakpoint.  If the thread-specific
 # breakpoint works, the next stop will be on the main thread.
-setter_method(main_thread, thread_breakpoint)
+setter_method(self, main_thread, thread_breakpoint)
 
 process.Continue()
 next_stop_state = process.GetState()



___
lldb-commi

[Lldb-commits] [PATCH] D107015: Add "current" token for the -t option to "break set/modify"

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf362b05d0dcd: Add a "current" token to the 
ThreadID option to break set/modify. (authored by jingham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107015

Files:
  lldb/source/Commands/CommandObjectBreakpoint.cpp
  lldb/source/Commands/Options.td
  
lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py


Index: 
lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
===
--- 
lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
+++ 
lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
@@ -9,11 +9,15 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
-def set_thread_id(thread, breakpoint):
+def using_current(test, thread, breakpoint):
+bp_id = breakpoint.GetID()
+test.runCmd("break modify -t current {0}".format(bp_id))
+
+def set_thread_id(test, thread, breakpoint):
 id = thread.id
 breakpoint.SetThreadID(id)
 
-def set_thread_name(thread, breakpoint):
+def set_thread_name(test, thread, breakpoint):
 breakpoint.SetThreadName("main-thread")
 
 class ThreadSpecificBreakTestCase(TestBase):
@@ -32,6 +36,10 @@
 def test_thread_name(self):
 self.do_test(set_thread_name)
 
+@expectedFailureAll(oslist=['ios', 'watchos', 'tvos', 'bridgeos'], 
archs=['armv7', 'armv7k'], bugnumber='rdar://problem/34563920') # armv7 ios 
problem - breakpoint with tid qualifier isn't working
+def test_current_token(self):
+self.do_test(using_current)
+
 def do_test(self, setter_method):
 """Test that we obey thread conditioned breakpoints."""
 self.build()
@@ -51,7 +59,7 @@
 # thread joins the secondary thread, and then the main thread will
 # execute the code at the breakpoint.  If the thread-specific
 # breakpoint works, the next stop will be on the main thread.
-setter_method(main_thread, thread_breakpoint)
+setter_method(self, main_thread, thread_breakpoint)
 
 process.Continue()
 next_stop_state = process.GetState()
Index: lldb/source/Commands/Options.td
===
--- lldb/source/Commands/Options.td
+++ lldb/source/Commands/Options.td
@@ -73,7 +73,7 @@
 "index matches this argument.">;
   def breakpoint_modify_thread_id : Option<"thread-id", "t">, Group<1>,
 Arg<"ThreadID">, Desc<"The breakpoint stops only for the thread whose TID "
-"matches this argument.">;
+"matches this argument.  The token 'current' resolves to the current 
thread's ID.">;
   def breakpoint_modify_thread_name : Option<"thread-name", "T">, Group<1>,
 Arg<"ThreadName">, Desc<"The breakpoint stops only for the thread whose "
 "thread name matches this argument.">;
Index: lldb/source/Commands/CommandObjectBreakpoint.cpp
===
--- lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -110,7 +110,19 @@
 case 't': {
   lldb::tid_t thread_id = LLDB_INVALID_THREAD_ID;
   if (option_arg[0] != '\0') {
-if (option_arg.getAsInteger(0, thread_id))
+if (option_arg == "current") {
+  if (!execution_context) {
+error.SetErrorStringWithFormat("No context to determine current "
+   "thread");
+  } else {
+ThreadSP ctx_thread_sp = execution_context->GetThreadSP();
+if (!ctx_thread_sp || !ctx_thread_sp->IsValid()) {
+  error.SetErrorStringWithFormat("No currently selected thread");
+} else {
+  thread_id = ctx_thread_sp->GetID();
+}
+  }
+} else if (option_arg.getAsInteger(0, thread_id))
   error.SetErrorStringWithFormat("invalid thread id string '%s'",
  option_arg.str().c_str());
   }


Index: lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
===
--- lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
+++ lldb/test/API/functionalities/thread/thread_specific_break/TestThreadSpecificBreakpoint.py
@@ -9,11 +9,15 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
-def set_thread_id(thread, breakpoint):
+def using_current(test, thread, breakpoint):
+bp_id = breakpoint.GetID()
+test.runCmd("break modify 

[Lldb-commits] [PATCH] D107673: Use LC_DYLD_EXPORTS_TRIE to locate the dyld trie structure if present

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
jingham created this revision.
jingham added a reviewer: JDevlieghere.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

The pointer to the dyld trie data structure which lldb needs to parse to get 
"trampoline kinds" on Darwin used to be a field in the LC_DYLD_INFO load 
command.  A new load command was added recently dedicated to this purpose: 
LC_DYLD_EXPORTS_TRIE.  The format of the trie did not change, however.  So all 
we have to do is use the new command if present.  The commands are supposed to 
be mutually exclusive, so I added an lldb_assert to warn if they are not.

Without this patch TestIndirectSymbols.py fails on systems that use the new 
command, so there wasn't a need to write a test for this change.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107673

Files:
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp


Index: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
===
--- lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2221,6 +2221,7 @@
 
   llvm::MachO::symtab_command symtab_load_command = {0, 0, 0, 0, 0, 0};
   llvm::MachO::linkedit_data_command function_starts_load_command = {0, 0, 0, 
0};
+  llvm::MachO::linkedit_data_command exports_trie_load_command = {0, 0, 0, 0};
   llvm::MachO::dyld_info_command dyld_info = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
   // The data element of type bool indicates that this entry is thumb
   // code.
@@ -2298,11 +2299,19 @@
   }
 } break;
 
+case LC_DYLD_EXPORTS_TRIE:
+  exports_trie_load_command.cmd = lc.cmd;
+  exports_trie_load_command.cmdsize = lc.cmdsize;
+  if (m_data.GetU32(&offset, &exports_trie_load_command.dataoff, 2) ==
+  nullptr) // fill in offset and size fields
+memset(&exports_trie_load_command, 0,
+   sizeof(exports_trie_load_command));
+  break;
 case LC_FUNCTION_STARTS:
   function_starts_load_command.cmd = lc.cmd;
   function_starts_load_command.cmdsize = lc.cmdsize;
   if (m_data.GetU32(&offset, &function_starts_load_command.dataoff, 2) ==
-  nullptr) // fill in symoff, nsyms, stroff, strsize fields
+  nullptr) // fill in data offset and size fields
 memset(&function_starts_load_command, 0,
sizeof(function_starts_load_command));
   break;
@@ -2446,6 +2455,7 @@
   dyld_info.export_off += linkedit_slide;
   m_dysymtab.indirectsymoff += linkedit_slide;
   function_starts_load_command.dataoff += linkedit_slide;
+  exports_trie_load_command.dataoff += linkedit_slide;
 }
 
 nlist_data.SetData(m_data, symtab_load_command.symoff,
@@ -2453,9 +2463,16 @@
 strtab_data.SetData(m_data, symtab_load_command.stroff,
 strtab_data_byte_size);
 
+// We shouldn't have exports data from both the LC_DYLD_INFO command
+// AND the LC_DYLD_EXPORTS_TRIE command in the same binary:
+lldbassert(!((dyld_info.export_size > 0) 
+ && (exports_trie_load_command.datasize > 0)));
 if (dyld_info.export_size > 0) {
   dyld_trie_data.SetData(m_data, dyld_info.export_off,
  dyld_info.export_size);
+} else if (exports_trie_load_command.datasize > 0) {
+  dyld_trie_data.SetData(m_data, exports_trie_load_command.dataoff,
+ exports_trie_load_command.datasize);
 }
 
 if (m_dysymtab.nindirectsyms != 0) {


Index: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
===
--- lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2221,6 +2221,7 @@
 
   llvm::MachO::symtab_command symtab_load_command = {0, 0, 0, 0, 0, 0};
   llvm::MachO::linkedit_data_command function_starts_load_command = {0, 0, 0, 0};
+  llvm::MachO::linkedit_data_command exports_trie_load_command = {0, 0, 0, 0};
   llvm::MachO::dyld_info_command dyld_info = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
   // The data element of type bool indicates that this entry is thumb
   // code.
@@ -2298,11 +2299,19 @@
   }
 } break;
 
+case LC_DYLD_EXPORTS_TRIE:
+  exports_trie_load_command.cmd = lc.cmd;
+  exports_trie_load_command.cmdsize = lc.cmdsize;
+  if (m_data.GetU32(&offset, &exports_trie_load_command.dataoff, 2) ==
+  nullptr) // fill in offset and size fields
+memset(&exports_trie_load_command, 0,
+   sizeof(exports_trie_load_command));
+  break;
 case LC_FUNCTION_STARTS:
   function_starts_load_command.cmd = lc.cmd;
   function_starts_load_command.cmdsize = lc.cmdsize;
   if (m_data.GetU32(&offset, &function_starts_load_command.dataoff, 2) ==
-  nullptr) // fill in symoff, nsyms, stroff, strsi

[Lldb-commits] [PATCH] D107673: Use LC_DYLD_EXPORTS_TRIE to locate the dyld trie structure if present

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107673

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


[Lldb-commits] [PATCH] D107674: [tests] [trace] Add more comprehensive for `thread trace export ctf` command

2021-08-06 Thread Jakob Johnson via Phabricator via lldb-commits
jj10306 created this revision.
jj10306 added a reviewer: wallace.
jj10306 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Follow up on https://reviews.llvm.org/D105741

- Add new test that exhaustively checks the output file's content
- Fix typos in documentation and other minor fixes


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107674

Files:
  lldb/docs/htr.rst
  lldb/source/Plugins/TraceExporter/common/TraceHTR.cpp
  lldb/source/Plugins/TraceExporter/common/TraceHTR.h
  lldb/test/API/commands/trace/TestTraceExport.py

Index: lldb/test/API/commands/trace/TestTraceExport.py
===
--- lldb/test/API/commands/trace/TestTraceExport.py
+++ lldb/test/API/commands/trace/TestTraceExport.py
@@ -47,9 +47,97 @@
 self.assertTrue(os.path.exists(ctf_test_file))
 
 
-def testHtrBasicSuperBlockPass(self):
+def testHtrBasicSuperBlockPassFullCheck(self):
 '''
-Test the BasicSuperBlock pass of HTR
+Test the BasicSuperBlock pass of HTR.
+
+This test uses a very small trace so that the expected output is digestible and
+it's possible to manually verify the behavior of the algorithm.
+
+This test exhaustively checks that each entry
+in the output JSON is equal to the expected value.
+
+'''
+
+self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"),
+substrs=["intel-pt"])
+
+ctf_test_file = self.getBuildArtifact("ctf-test.json")
+
+if os.path.exists(ctf_test_file):
+remove_file(ctf_test_file)
+self.expect(f"thread trace export ctf --file {ctf_test_file}")
+self.assertTrue(os.path.exists(ctf_test_file))
+
+with open(ctf_test_file) as f:
+data = json.load(f)
+
+'''
+The expected JSON contained by "ctf-test.json"
+
+dur: number of instructions in the block
+
+name: load address of the first instruction of the block and the
+name of the most frequently called function from the block (if applicable)
+
+ph: 'X' for Complete events (see link to documentation below)
+
+pid: the ID of the HTR layer the blocks belong to
+
+ts: offset from the beginning of the trace for the first instruction in the block
+
+See https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview#heading=h.j75x71ritcoy
+for documentation on the Trace Event Format
+'''
+# Comments on the right indicate if a block is a "head" and/or "tail"
+# See BasicSuperBlockMerge in TraceHTR.h for a description of the algorithm
+expected = [
+{"dur":1,"name":"0x400511","ph":"X","pid":0,"ts":0},
+{"dur":1,"name":"0x400518","ph":"X","pid":0,"ts":1},
+{"dur":1,"name":"0x40051f","ph":"X","pid":0,"ts":2},
+{"dur":1,"name":"0x400529","ph":"X","pid":0,"ts":3}, # head
+{"dur":1,"name":"0x40052d","ph":"X","pid":0,"ts":4}, # tail
+{"dur":1,"name":"0x400521","ph":"X","pid":0,"ts":5},
+{"dur":1,"name":"0x400525","ph":"X","pid":0,"ts":6},
+{"dur":1,"name":"0x400529","ph":"X","pid":0,"ts":7}, # head
+{"dur":1,"name":"0x40052d","ph":"X","pid":0,"ts":8}, # tail
+{"dur":1,"name":"0x400521","ph":"X","pid":0,"ts":9},
+{"dur":1,"name":"0x400525","ph":"X","pid":0,"ts":10},
+{"dur":1,"name":"0x400529","ph":"X","pid":0,"ts":11}, # head
+{"dur":1,"name":"0x40052d","ph":"X","pid":0,"ts":12}, # tail
+{"dur":1,"name":"0x400521","ph":"X","pid":0,"ts":13},
+{"dur":1,"name":"0x400525","ph":"X","pid":0,"ts":14},
+{"dur":1,"name":"0x400529","ph":"X","pid":0,"ts":15}, # head
+{"dur":1,"name":"0x40052d","ph":"X","pid":0,"ts":16}, # tail
+{"dur":1,"name":"0x400521","ph":"X","pid":0,"ts":17},
+{"dur":1,"name":"0x400525","ph":"X","pid":0,"ts":18},
+{"dur":1,"name":"0x400529","ph":"X","pid":0,"ts":19}, # head
+{"dur":1,"name":"0x40052d","ph":"X","pid":0,"ts":20}, # tail
+{"args":{"Metadata":{"Functions":[],"Number of Instructions":3}},"dur":3,"name":"0x400511","ph":"X","pid":1,"ts":0},
+{"args":{"Metadata":{"Functions":[],"Number of Instructions":2}},"dur":2,"name":"0x400529","ph":"X","pid":1,"ts":3}, # head, tail
+{"args":{"Metadata":{"Functions":[],"Number of Instructions":2}},"dur":2,"name":"0x400521","ph":"X","pid":1,"ts":5},
+{"args":{"Metadata":{"Functions":[],"Number of Instructions":2}},"dur":2,"name":"0x400529","ph":"X","pid":1,"ts":7}, # head, tail
+{"args":{"Metadata":{"Functions":[],"Number of Instructions":2}},"dur":2,"name":"0x400521","ph":"X","pid":1,"ts":9},
+{"args":{"Metadata":{"Functions":[

[Lldb-commits] [lldb] 34d78b6 - [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-08-06T16:08:48-07:00
New Revision: 34d78b6a6755946e547afc47d38b59b6a2854457

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

LOG: [lldb] Upstream support for Foundation constant classes

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.

I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.

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

Added: 

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py

Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp
lldb/source/Plugins/Language/ObjC/NSArray.cpp
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py

lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
lldb/test/API/lang/objc/orderedset/TestOrderedSet.py

lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index 1479f4f0c151..e5dcf8441bb6 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "Cocoa.h"
+#include "objc/runtime.h"
 
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/Core/Mangled.h"
@@ -456,6 +457,72 @@ bool lldb_private::formatters::NSNumberSummaryProvider(
   if (class_name == "NSDecimalNumber")
 return NSDecimalNumberSummaryProvider(valobj, stream, options);
 
+  if (class_name == "NSConstantIntegerNumber") {
+Status error;
+int64_t value = process_sp->ReadSignedIntegerFromMemory(
+valobj_addr + 2 * ptr_size, 8, 0, error);
+if (error.Fail())
+  return false;
+uint64_t encoding_addr = process_sp->ReadUnsignedIntegerFromMemory(
+valobj_addr + ptr_size, ptr_size, 0, error);
+if (error.Fail())
+  return false;
+char encoding =
+process_sp->ReadUnsignedIntegerFromMemory(encoding_addr, 1, 0, error);
+if (error.Fail())
+  return false;
+
+switch (encoding) {
+case _C_CHR:
+  NSNumber_FormatChar(valobj, stream, (char)value, options.GetLanguage());
+  return true;
+case _C_SHT:
+  NSNumber_FormatShort(valobj, stream, (short)value, 
options.GetLanguage());
+  return true;
+case _C_INT:
+  NSNumber_FormatInt(valobj, stream, (int)value, options.GetLanguage());
+  return true;
+case _C_LNG:
+case _C_LNG_LNG:
+  NSNumber_FormatLong(valobj, stream, value, options.GetLanguage());
+  return true;
+
+case _C_UCHR:
+case _C_USHT:
+case _C_UINT:
+case _C_ULNG:
+case _C_ULNG_LNG:
+  stream.Printf("%" PRIu64, value);
+  return true;
+}
+
+return false;
+  }
+
+  if (class_name == "NSConstantFloatNumber") {
+Status error;
+uint32_t flt_as_int = process_sp->ReadUnsignedIntegerFromMemory(
+valobj_addr + ptr_size, 4, 0, error);
+if (error.Fail())
+  return false;
+float flt_value = 0.0f;
+memcpy(&flt_value, &flt_as_int, sizeof(flt_as_int));
+NSNumber_FormatFloat(valobj, stream, flt_value, options.GetLanguage());
+return true;
+  }
+

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere 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 rG34d78b6a6755: [lldb] Upstream support for Foundation 
constant classes (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D107660?vs=364869&id=364905#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  lldb/source/Plugins/Language/ObjC/NSArray.cpp
  lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
  lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
  
lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py
  lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
  lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
  lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
  
lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Index: lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
===
--- lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
+++ lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py
@@ -21,9 +21,27 @@
 # Find the line number to break inside main().
 self.line = line_number('main.m', '// break here')
 
+@skipUnlessDarwin
 @expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
 def test_single_entry_dict(self):
 self.build()
+self.run_tests()
+
+@skipUnlessDarwin
+@expectedFailureAll(oslist=['watchos'], bugnumber="rdar://problem/34642736") # bug in NSDictionary formatting on watchos
+def test_single_entry_dict_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+def run_tests(self):
 exe = self.getBuildArtifact("a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
Index: lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
===
--- lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
+++ lldb/test/API/lang/objc/orderedset/TestOrderedSet.py
@@ -8,6 +8,22 @@
 
   def test_ordered_set(self):
 self.build()
+self.run_tests()
+
+  @skipUnlessDarwin
+  def test_ordered_set_no_const(self):
+disable_constant_classes = {
+'CC':
+'xcrun clang',  # FIXME: Remove when flags are available upstream.
+'CFLAGS_EXTRAS':
+'-fno-constant-nsnumber-literals ' +
+'-fno-constant-nsarray-literals ' +
+'-fno-constant-nsdictionary-literals'
+}
+self.build(dictionary=disable_constant_classes)
+self.run_tests()
+
+  def run_tests(self):
 src_file = "main.m"
 src_file_spec = lldb.SBFileSpec(src_file)
 (target, process, thread, main_breakpoint) = lldbutil.run_to_source_breakpoint(self,
Index: lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
===
--- lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
+++ lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
@@ -20,6 +20,20 @@
 self.build()
 self.printarray_data_formatter_commands()
 
+@skipUnlessDarwin
+def test_print_array_no_const(self):
+"""Test that expr -O -Z works"""
+   

[Lldb-commits] [lldb] bfeb281 - Use LC_DYLD_EXPORTS_TRIE to locate the dyld trie structure if present

2021-08-06 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2021-08-06T16:38:34-07:00
New Revision: bfeb281fbd8e348edfadf5052e9266e13b832171

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

LOG: Use LC_DYLD_EXPORTS_TRIE to locate the dyld trie structure if present

The pointer to the dyld trie data structure which lldb needs to parse to get
"trampoline kinds" on Darwin used to be a field in the LC_DYLD_INFO load 
command. A
new load command was added recently dedicated to this purpose: 
LC_DYLD_EXPORTS_TRIE.
The format of the trie did not change, however. So all we have to do is use the 
new
command if present. The commands are supposed to be mutually exclusive, so I 
added
an lldb_assert to warn if they are not.

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

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index fd1a23d5024a..e5ee13295b9c 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2221,6 +2221,7 @@ size_t ObjectFileMachO::ParseSymtab() {
 
   llvm::MachO::symtab_command symtab_load_command = {0, 0, 0, 0, 0, 0};
   llvm::MachO::linkedit_data_command function_starts_load_command = {0, 0, 0, 
0};
+  llvm::MachO::linkedit_data_command exports_trie_load_command = {0, 0, 0, 0};
   llvm::MachO::dyld_info_command dyld_info = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
   // The data element of type bool indicates that this entry is thumb
   // code.
@@ -2298,11 +2299,19 @@ size_t ObjectFileMachO::ParseSymtab() {
   }
 } break;
 
+case LC_DYLD_EXPORTS_TRIE:
+  exports_trie_load_command.cmd = lc.cmd;
+  exports_trie_load_command.cmdsize = lc.cmdsize;
+  if (m_data.GetU32(&offset, &exports_trie_load_command.dataoff, 2) ==
+  nullptr) // fill in offset and size fields
+memset(&exports_trie_load_command, 0,
+   sizeof(exports_trie_load_command));
+  break;
 case LC_FUNCTION_STARTS:
   function_starts_load_command.cmd = lc.cmd;
   function_starts_load_command.cmdsize = lc.cmdsize;
   if (m_data.GetU32(&offset, &function_starts_load_command.dataoff, 2) ==
-  nullptr) // fill in symoff, nsyms, stroff, strsize fields
+  nullptr) // fill in data offset and size fields
 memset(&function_starts_load_command, 0,
sizeof(function_starts_load_command));
   break;
@@ -2446,6 +2455,7 @@ size_t ObjectFileMachO::ParseSymtab() {
   dyld_info.export_off += linkedit_slide;
   m_dysymtab.indirectsymoff += linkedit_slide;
   function_starts_load_command.dataoff += linkedit_slide;
+  exports_trie_load_command.dataoff += linkedit_slide;
 }
 
 nlist_data.SetData(m_data, symtab_load_command.symoff,
@@ -2453,9 +2463,16 @@ size_t ObjectFileMachO::ParseSymtab() {
 strtab_data.SetData(m_data, symtab_load_command.stroff,
 strtab_data_byte_size);
 
+// We shouldn't have exports data from both the LC_DYLD_INFO command
+// AND the LC_DYLD_EXPORTS_TRIE command in the same binary:
+lldbassert(!((dyld_info.export_size > 0) 
+ && (exports_trie_load_command.datasize > 0)));
 if (dyld_info.export_size > 0) {
   dyld_trie_data.SetData(m_data, dyld_info.export_off,
  dyld_info.export_size);
+} else if (exports_trie_load_command.datasize > 0) {
+  dyld_trie_data.SetData(m_data, exports_trie_load_command.dataoff,
+ exports_trie_load_command.datasize);
 }
 
 if (m_dysymtab.nindirectsyms != 0) {



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


[Lldb-commits] [PATCH] D107673: Use LC_DYLD_EXPORTS_TRIE to locate the dyld trie structure if present

2021-08-06 Thread Jim Ingham 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 rGbfeb281fbd8e: Use LC_DYLD_EXPORTS_TRIE to locate the dyld 
trie structure if present (authored by jingham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107673

Files:
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp


Index: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
===
--- lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2221,6 +2221,7 @@
 
   llvm::MachO::symtab_command symtab_load_command = {0, 0, 0, 0, 0, 0};
   llvm::MachO::linkedit_data_command function_starts_load_command = {0, 0, 0, 
0};
+  llvm::MachO::linkedit_data_command exports_trie_load_command = {0, 0, 0, 0};
   llvm::MachO::dyld_info_command dyld_info = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0};
   // The data element of type bool indicates that this entry is thumb
   // code.
@@ -2298,11 +2299,19 @@
   }
 } break;
 
+case LC_DYLD_EXPORTS_TRIE:
+  exports_trie_load_command.cmd = lc.cmd;
+  exports_trie_load_command.cmdsize = lc.cmdsize;
+  if (m_data.GetU32(&offset, &exports_trie_load_command.dataoff, 2) ==
+  nullptr) // fill in offset and size fields
+memset(&exports_trie_load_command, 0,
+   sizeof(exports_trie_load_command));
+  break;
 case LC_FUNCTION_STARTS:
   function_starts_load_command.cmd = lc.cmd;
   function_starts_load_command.cmdsize = lc.cmdsize;
   if (m_data.GetU32(&offset, &function_starts_load_command.dataoff, 2) ==
-  nullptr) // fill in symoff, nsyms, stroff, strsize fields
+  nullptr) // fill in data offset and size fields
 memset(&function_starts_load_command, 0,
sizeof(function_starts_load_command));
   break;
@@ -2446,6 +2455,7 @@
   dyld_info.export_off += linkedit_slide;
   m_dysymtab.indirectsymoff += linkedit_slide;
   function_starts_load_command.dataoff += linkedit_slide;
+  exports_trie_load_command.dataoff += linkedit_slide;
 }
 
 nlist_data.SetData(m_data, symtab_load_command.symoff,
@@ -2453,9 +2463,16 @@
 strtab_data.SetData(m_data, symtab_load_command.stroff,
 strtab_data_byte_size);
 
+// We shouldn't have exports data from both the LC_DYLD_INFO command
+// AND the LC_DYLD_EXPORTS_TRIE command in the same binary:
+lldbassert(!((dyld_info.export_size > 0) 
+ && (exports_trie_load_command.datasize > 0)));
 if (dyld_info.export_size > 0) {
   dyld_trie_data.SetData(m_data, dyld_info.export_off,
  dyld_info.export_size);
+} else if (exports_trie_load_command.datasize > 0) {
+  dyld_trie_data.SetData(m_data, exports_trie_load_command.dataoff,
+ exports_trie_load_command.datasize);
 }
 
 if (m_dysymtab.nindirectsyms != 0) {


Index: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
===
--- lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -2221,6 +2221,7 @@
 
   llvm::MachO::symtab_command symtab_load_command = {0, 0, 0, 0, 0, 0};
   llvm::MachO::linkedit_data_command function_starts_load_command = {0, 0, 0, 0};
+  llvm::MachO::linkedit_data_command exports_trie_load_command = {0, 0, 0, 0};
   llvm::MachO::dyld_info_command dyld_info = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
   // The data element of type bool indicates that this entry is thumb
   // code.
@@ -2298,11 +2299,19 @@
   }
 } break;
 
+case LC_DYLD_EXPORTS_TRIE:
+  exports_trie_load_command.cmd = lc.cmd;
+  exports_trie_load_command.cmdsize = lc.cmdsize;
+  if (m_data.GetU32(&offset, &exports_trie_load_command.dataoff, 2) ==
+  nullptr) // fill in offset and size fields
+memset(&exports_trie_load_command, 0,
+   sizeof(exports_trie_load_command));
+  break;
 case LC_FUNCTION_STARTS:
   function_starts_load_command.cmd = lc.cmd;
   function_starts_load_command.cmdsize = lc.cmdsize;
   if (m_data.GetU32(&offset, &function_starts_load_command.dataoff, 2) ==
-  nullptr) // fill in symoff, nsyms, stroff, strsize fields
+  nullptr) // fill in data offset and size fields
 memset(&function_starts_load_command, 0,
sizeof(function_starts_load_command));
   break;
@@ -2446,6 +2455,7 @@
   dyld_info.export_off += linkedit_slide;
   m_dysymtab.indirectsymoff += linkedit_slide;
   function_starts_load_command.dataoff += linkedit_slide;
+  exports_trie_load_command.dataoff += linkedit_slide;
 }
 
 nlist_data.SetData(m_d

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Sterling Augustine via Phabricator via lldb-commits
saugustine added a comment.

This change breaks various build bots with a missing file. See below. Reverting 
shortly.

For example:

https://lab.llvm.org/buildbot/#/builders/68/builds/16816

/usr/bin/clang++  -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/lldb/source/Plugins/Language/ObjC 
-I/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC
 -Itools/lldb/source 
-I/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/include 
-Itools/lldb/include -Iinclude 
-I/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/include 
-I/usr/include/python3.7m 
-I/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/../clang/include 
-Itools/lldb/../clang/include 
-I/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/. -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
-Wno-vla-extension -O3 -DNDEBUG-fno-exceptions -fno-rtti -UNDEBUG 
-std=c++14 -MD -MT 
tools/lldb/source/Plugins/Language/ObjC/CMakeFiles/lldbPluginObjCLanguage.dir/Cocoa.cpp.o
 -MF 
tools/lldb/source/Plugins/Language/ObjC/CMakeFiles/lldbPluginObjCLanguage.dir/Cocoa.cpp.o.d
 -o 
tools/lldb/source/Plugins/Language/ObjC/CMakeFiles/lldbPluginObjCLanguage.dir/Cocoa.cpp.o
 -c 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10:
 fatal error: 'objc/runtime.h' file not found
#include "objc/runtime.h"

  ^~~~


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

Yep, I'm looking into it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [lldb] 4e5af6e - Revert "[lldb] Upstream support for Foundation constant classes"

2021-08-06 Thread Sterling Augustine via lldb-commits

Author: Sterling Augustine
Date: 2021-08-06T16:56:59-07:00
New Revision: 4e5af6ef48590e7248e344ddabf245bb3de71c51

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

LOG: Revert "[lldb] Upstream support for Foundation constant classes"

This reverts commit 34d78b6a6755946e547afc47d38b59b6a2854457.

This breaks build bots witha  missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10:
 fatal error: 'objc/runtime.h' file not found

Added: 


Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp
lldb/source/Plugins/Language/ObjC/NSArray.cpp
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py

lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
lldb/test/API/lang/objc/orderedset/TestOrderedSet.py

lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Removed: 

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py



diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index e5dcf8441bb6..1479f4f0c151 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -7,7 +7,6 @@
 
//===--===//
 
 #include "Cocoa.h"
-#include "objc/runtime.h"
 
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/Core/Mangled.h"
@@ -457,72 +456,6 @@ bool lldb_private::formatters::NSNumberSummaryProvider(
   if (class_name == "NSDecimalNumber")
 return NSDecimalNumberSummaryProvider(valobj, stream, options);
 
-  if (class_name == "NSConstantIntegerNumber") {
-Status error;
-int64_t value = process_sp->ReadSignedIntegerFromMemory(
-valobj_addr + 2 * ptr_size, 8, 0, error);
-if (error.Fail())
-  return false;
-uint64_t encoding_addr = process_sp->ReadUnsignedIntegerFromMemory(
-valobj_addr + ptr_size, ptr_size, 0, error);
-if (error.Fail())
-  return false;
-char encoding =
-process_sp->ReadUnsignedIntegerFromMemory(encoding_addr, 1, 0, error);
-if (error.Fail())
-  return false;
-
-switch (encoding) {
-case _C_CHR:
-  NSNumber_FormatChar(valobj, stream, (char)value, options.GetLanguage());
-  return true;
-case _C_SHT:
-  NSNumber_FormatShort(valobj, stream, (short)value, 
options.GetLanguage());
-  return true;
-case _C_INT:
-  NSNumber_FormatInt(valobj, stream, (int)value, options.GetLanguage());
-  return true;
-case _C_LNG:
-case _C_LNG_LNG:
-  NSNumber_FormatLong(valobj, stream, value, options.GetLanguage());
-  return true;
-
-case _C_UCHR:
-case _C_USHT:
-case _C_UINT:
-case _C_ULNG:
-case _C_ULNG_LNG:
-  stream.Printf("%" PRIu64, value);
-  return true;
-}
-
-return false;
-  }
-
-  if (class_name == "NSConstantFloatNumber") {
-Status error;
-uint32_t flt_as_int = process_sp->ReadUnsignedIntegerFromMemory(
-valobj_addr + ptr_size, 4, 0, error);
-if (error.Fail())
-  return false;
-float flt_value = 0.0f;
-memcpy(&flt_value, &flt_as_int, sizeof(flt_as_int));
-NSNumber_FormatFloat(valobj, stream, flt_value, options.GetLanguage());
-return true;
-  }
-
-  if (class_name == "NSConstantDoubleNumber") {
-Status error;
-uint64_t dbl_as_lng = process_sp->ReadUnsignedIntegerFromMemory(
-valobj_addr + ptr_size, 8, 0, error);
-if (error.Fail())
-  return false;
-double dbl_value = 0.0;
-memcpy(&dbl_value, &dbl_as_lng, siz

[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Sterling Augustine via Phabricator via lldb-commits
saugustine added a comment.

Thanks for looking. Reverted with 4e5af6ef48590e7248e344ddabf245bb3de71c51 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D107660#2932321 , @saugustine 
wrote:

> Thanks for looking. Reverted with 4e5af6ef48590e7248e344ddabf245bb3de71c51 
> .

What's the point of giving a heads up if you're goin to revert it immediately, 
even after you know I'm already looking into it? To be clear, I have no issue 
with the revert-to-green policy, I do it all the time myself, but if you're 
going to do that, you might as well revert it right away and skip the heads up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107386: [LLDB][GUI] Add Breakpoints window

2021-08-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

I like the new UI! I think you are right in that we don't need the address on 
the breakpoint location line if we can expand it and see it in the location 
children, so lets remove it from there. Other than that it looks good. The only 
other suggestion I would have is if we should display "1.1" and "1.2" for the 
breakpoint locations. This will match the output of "breakpoint list" a bit 
better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107386

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Sterling Augustine via Phabricator via lldb-commits
saugustine added a comment.

Some people complain if I revert without notification. So I always notify as 
soon as I find the patch with the problem. Some reverts are more complicated 
than others too.

I guess it adds more noise but I try to default to more communication over less.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [PATCH] D107660: [lldb] Upstream support for Foundation constant classes

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D107660#2932334 , @saugustine 
wrote:

> Some people complain if I revert without notification. So I always notify as 
> soon as I find the patch with the problem. Some reverts are more complicated 
> than others too.
>
> I guess it adds more noise but I try to default to more communication over 
> less.

Gotcha, I was genuinely curious, thanks for the context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107660

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


[Lldb-commits] [lldb] 9d5e95d - Re-land "[lldb] Upstream support for Foundation constant classes"

2021-08-06 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-08-06T17:24:47-07:00
New Revision: 9d5e95d094ffc1a49aa4c9d379cec7c2b60fd3f2

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

LOG: Re-land "[lldb] Upstream support for Foundation constant classes"

Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.

We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.

I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.

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

Added: 

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSNumber.py

Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp
lldb/source/Plugins/Language/ObjC/NSArray.cpp
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

lldb/test/API/functionalities/data-formatter/nsdictionarysynth/TestNSDictionarySynthetic.py

lldb/test/API/functionalities/data-formatter/nssetsynth/TestNSSetSynthetic.py
lldb/test/API/functionalities/data-formatter/poarray/TestPrintObjectArray.py
lldb/test/API/lang/objc/orderedset/TestOrderedSet.py

lldb/test/API/lang/objc/single-entry-dictionary/TestObjCSingleEntryDictionary.py

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index 1479f4f0c151..27017789e5f2 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -7,7 +7,9 @@
 
//===--===//
 
 #include "Cocoa.h"
+#include "NSString.h"
 
+#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h"
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/Core/Mangled.h"
 #include "lldb/Core/ValueObject.h"
@@ -28,9 +30,37 @@
 #include "llvm/ADT/APInt.h"
 #include "llvm/ADT/bit.h"
 
-#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h"
-
-#include "NSString.h"
+// Objective-C Type Encoding
+#define _C_ID   '@'
+#define _C_CLASS'#'
+#define _C_SEL  ':'
+#define _C_CHR  'c'
+#define _C_UCHR 'C'
+#define _C_SHT  's'
+#define _C_USHT 'S'
+#define _C_INT  'i'
+#define _C_UINT 'I'
+#define _C_LNG  'l'
+#define _C_ULNG 'L'
+#define _C_LNG_LNG  'q'
+#define _C_ULNG_LNG 'Q'
+#define _C_FLT  'f'
+#define _C_DBL  'd'
+#define _C_BFLD 'b'
+#define _C_BOOL 'B'
+#define _C_VOID 'v'
+#define _C_UNDEF'?'
+#define _C_PTR  '^'
+#define _C_CHARPTR  '*'
+#define _C_ATOM '%'
+#define _C_ARY_B'['
+#define _C_ARY_E']'
+#define _C_UNION_B  '('
+#define _C_UNION_E  ')'
+#define _C_STRUCT_B '{'
+#define _C_STRUCT_E '}'
+#define _C_VECTOR   '!'
+#define _C_CONST'r'
 
 using namespace lldb;
 using namespace lldb_private;
@@ -456,6 +486,72 @@ bool lldb_private::formatters::NSNumberSummaryProvider(
   if (class_name == "NSDecimalNumber")
 return NSDecimalNumberSummaryProvider(valobj, stream, options);
 
+  if (class_name == "NSConstantIntegerNumber") {
+Status error;
+int64_t value = process_sp->ReadSignedIntegerFromMemory(
+valobj_addr + 2 * ptr_size, 8, 0, error);
+if (error.Fail())
+  return false;
+uint64_t encoding_addr = process_sp->ReadUnsignedIntegerFromMemory(
+valobj_addr + ptr_size, ptr_size, 0, error);
+if (error.Fail())
+  return false;
+char encoding =
+process_sp->ReadUnsignedIntegerFromMemory(encoding_addr, 1, 0, error);
+if (error.Fail())
+  return fa

[Lldb-commits] [PATCH] D107679: [lldb] Move Objective-C constants into ObjCConstants.h

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added a reviewer: jingham.
JDevlieghere requested review of this revision.

Move Objective-C constants into ObjCConstants.h and share them between Cocoa 
and AppleObjCTypeEncodingParser.


https://reviews.llvm.org/D107679

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  lldb/source/Plugins/Language/ObjC/ObjCConstants.h
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h

Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
@@ -9,11 +9,11 @@
 #ifndef LLDB_SOURCE_PLUGINS_LANGUAGERUNTIME_OBJC_APPLEOBJCRUNTIME_APPLEOBJCTYPEENCODINGPARSER_H
 #define LLDB_SOURCE_PLUGINS_LANGUAGERUNTIME_OBJC_APPLEOBJCRUNTIME_APPLEOBJCTYPEENCODINGPARSER_H
 
-#include "clang/AST/ASTContext.h"
-
+#include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
+#include "Plugins/Language/ObjC/ObjCConstants.h"
 #include "lldb/lldb-private.h"
 
-#include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
+#include "clang/AST/ASTContext.h"
 
 namespace lldb_private {
 class StringLexer;
Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
@@ -78,13 +78,13 @@
 
 clang::QualType AppleObjCTypeEncodingParser::BuildStruct(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  return BuildAggregate(ast_ctx, type, for_expression, '{', '}',
+  return BuildAggregate(ast_ctx, type, for_expression, _C_STRUCT_B, _C_STRUCT_E,
 clang::TTK_Struct);
 }
 
 clang::QualType AppleObjCTypeEncodingParser::BuildUnion(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  return BuildAggregate(ast_ctx, type, for_expression, '(', ')',
+  return BuildAggregate(ast_ctx, type, for_expression, _C_UNION_B, _C_UNION_E,
 clang::TTK_Union);
 }
 
@@ -148,11 +148,11 @@
 
 clang::QualType AppleObjCTypeEncodingParser::BuildArray(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  if (!type.NextIf('['))
+  if (!type.NextIf(_C_ARY_B))
 return clang::QualType();
   uint32_t size = ReadNumber(type);
   clang::QualType element_type(BuildType(ast_ctx, type, for_expression));
-  if (!type.NextIf(']'))
+  if (!type.NextIf(_C_ARY_E))
 return clang::QualType();
   CompilerType array_type(ast_ctx.CreateArrayType(
   CompilerType(&ast_ctx, element_type.getAsOpaquePtr()), size, false));
@@ -166,7 +166,7 @@
 // dynamic typing will resolve things for us anyway
 clang::QualType AppleObjCTypeEncodingParser::BuildObjCObjectPointerType(
 TypeSystemClang &clang_ast_ctx, StringLexer &type, bool for_expression) {
-  if (!type.NextIf('@'))
+  if (!type.NextIf(_C_ID))
 return clang::QualType();
 
   clang::ASTContext &ast_ctx = clang_ast_ctx.getASTContext();
@@ -203,9 +203,9 @@
  2); // undo our consumption of the string and of the quotes
 name.clear();
 break;
-  case '}':
-  case ')':
-  case ']':
+  case _C_STRUCT_E:
+  case _C_UNION_E:
+  case _C_ARY_E:
   case '"':
 // the quoted string is a class name – see the rule
 break;
@@ -260,13 +260,13 @@
   switch (type.Peek()) {
   default:
 break;
-  case '{':
+  case _C_STRUCT_B:
 return BuildStruct(clang_ast_ctx, type, for_expression);
-  case '[':
+  case _C_ARY_B:
 return BuildArray(clang_ast_ctx, type, for_expression);
-  case '(':
+  case _C_UNION_B:
 return BuildUnion(clang_ast_ctx, type, for_expression);
-  case '@':
+  case _C_ID:
 return BuildObjCObjectPointerType(clang_ast_ctx, type, for_expression);
   }
 
@@ -274,46 +274,46 @@
   default:
 type.PutBack(1);
 return clang::QualType();
-  case 'c':
+  case _C_CHR:
 return ast_ctx.CharTy;
-  case 'i':
+  case _C_INT:
 return ast_ctx.IntTy;
-  case 's':
+  case _C_SHT:
 return ast_ctx.ShortTy;
-  case 'l':
+  case _C_LNG:
 return ast_ctx.getIntTypeForBitwidth(32, true);
   // this used to be done like this:
   //   return clang_ast_ctx->GetIntTypeFromBitSize(32, true).GetQualType();
   // which uses one of the constants if one is available, but we don't think
   // all this work is necessary.
-  case 'q':
+  case _C_LNG_LNG:
 return ast_ctx.LongLongTy;
-  case 'C':
+  case _C_UCHR:
 return ast_ctx.UnsignedCharTy;
-  case 'I':
+  case _C_UINT:
 return as

[Lldb-commits] [PATCH] D107679: [lldb] Move Objective-C constants into ObjCConstants.h

2021-08-06 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 364916.
JDevlieghere added a comment.

Formatting


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

https://reviews.llvm.org/D107679

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  lldb/source/Plugins/Language/ObjC/ObjCConstants.h
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h

Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.h
@@ -9,11 +9,11 @@
 #ifndef LLDB_SOURCE_PLUGINS_LANGUAGERUNTIME_OBJC_APPLEOBJCRUNTIME_APPLEOBJCTYPEENCODINGPARSER_H
 #define LLDB_SOURCE_PLUGINS_LANGUAGERUNTIME_OBJC_APPLEOBJCRUNTIME_APPLEOBJCTYPEENCODINGPARSER_H
 
-#include "clang/AST/ASTContext.h"
-
+#include "Plugins/Language/ObjC/ObjCConstants.h"
+#include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
 #include "lldb/lldb-private.h"
 
-#include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
+#include "clang/AST/ASTContext.h"
 
 namespace lldb_private {
 class StringLexer;
Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
@@ -78,13 +78,13 @@
 
 clang::QualType AppleObjCTypeEncodingParser::BuildStruct(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  return BuildAggregate(ast_ctx, type, for_expression, '{', '}',
+  return BuildAggregate(ast_ctx, type, for_expression, _C_STRUCT_B, _C_STRUCT_E,
 clang::TTK_Struct);
 }
 
 clang::QualType AppleObjCTypeEncodingParser::BuildUnion(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  return BuildAggregate(ast_ctx, type, for_expression, '(', ')',
+  return BuildAggregate(ast_ctx, type, for_expression, _C_UNION_B, _C_UNION_E,
 clang::TTK_Union);
 }
 
@@ -148,11 +148,11 @@
 
 clang::QualType AppleObjCTypeEncodingParser::BuildArray(
 TypeSystemClang &ast_ctx, StringLexer &type, bool for_expression) {
-  if (!type.NextIf('['))
+  if (!type.NextIf(_C_ARY_B))
 return clang::QualType();
   uint32_t size = ReadNumber(type);
   clang::QualType element_type(BuildType(ast_ctx, type, for_expression));
-  if (!type.NextIf(']'))
+  if (!type.NextIf(_C_ARY_E))
 return clang::QualType();
   CompilerType array_type(ast_ctx.CreateArrayType(
   CompilerType(&ast_ctx, element_type.getAsOpaquePtr()), size, false));
@@ -166,7 +166,7 @@
 // dynamic typing will resolve things for us anyway
 clang::QualType AppleObjCTypeEncodingParser::BuildObjCObjectPointerType(
 TypeSystemClang &clang_ast_ctx, StringLexer &type, bool for_expression) {
-  if (!type.NextIf('@'))
+  if (!type.NextIf(_C_ID))
 return clang::QualType();
 
   clang::ASTContext &ast_ctx = clang_ast_ctx.getASTContext();
@@ -203,9 +203,9 @@
  2); // undo our consumption of the string and of the quotes
 name.clear();
 break;
-  case '}':
-  case ')':
-  case ']':
+  case _C_STRUCT_E:
+  case _C_UNION_E:
+  case _C_ARY_E:
   case '"':
 // the quoted string is a class name – see the rule
 break;
@@ -260,13 +260,13 @@
   switch (type.Peek()) {
   default:
 break;
-  case '{':
+  case _C_STRUCT_B:
 return BuildStruct(clang_ast_ctx, type, for_expression);
-  case '[':
+  case _C_ARY_B:
 return BuildArray(clang_ast_ctx, type, for_expression);
-  case '(':
+  case _C_UNION_B:
 return BuildUnion(clang_ast_ctx, type, for_expression);
-  case '@':
+  case _C_ID:
 return BuildObjCObjectPointerType(clang_ast_ctx, type, for_expression);
   }
 
@@ -274,46 +274,46 @@
   default:
 type.PutBack(1);
 return clang::QualType();
-  case 'c':
+  case _C_CHR:
 return ast_ctx.CharTy;
-  case 'i':
+  case _C_INT:
 return ast_ctx.IntTy;
-  case 's':
+  case _C_SHT:
 return ast_ctx.ShortTy;
-  case 'l':
+  case _C_LNG:
 return ast_ctx.getIntTypeForBitwidth(32, true);
   // this used to be done like this:
   //   return clang_ast_ctx->GetIntTypeFromBitSize(32, true).GetQualType();
   // which uses one of the constants if one is available, but we don't think
   // all this work is necessary.
-  case 'q':
+  case _C_LNG_LNG:
 return ast_ctx.LongLongTy;
-  case 'C':
+  case _C_UCHR:
 return ast_ctx.UnsignedCharTy;
-  case 'I':
+  case _C_UINT:
 return ast_ctx.UnsignedIntTy;
-  case 'S':
+  case _C_USHT:
 return ast_ctx.Unsig

[Lldb-commits] [PATCH] D107679: [lldb] Move Objective-C constants into ObjCConstants.h

2021-08-06 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Nice, thanks for cleaning this up.


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

https://reviews.llvm.org/D107679

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