[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via lldb-commits 
thieta added a comment.

In D130689#3686397 , @thakis wrote:

> It'd be nice if this was landed opt-in behind some cmake variable at first, 
> so that folks could try it out on their bots and see how well things work.

You can already test this with `-DCMAKE_CXX_STANDARD=17` afaik. I wonder how 
many bot owners would actually test this if we made another flag available.

Since we can already test this with a current flag maybe we should just post to 
discourse that bot-owners can test it and a date when this will be merged. But 
I don't expect this to be a big problem, when we merged the soft error earlier 
this year - it only broke one bot which was out of date.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via lldb-commits 
thieta added a comment.

In D130689#3684399 , @h-vetinari 
wrote:

> It may be worth calling out that this is about C++17 core language and not 
> the standard library?
>
> libstdcxx only finished C++17 support in GCC 12, and libcxx is still missing 
> various pieces even today (much less for Clang 5).

I will add a small line about this in the coding standards document.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via lldb-commits 
thieta added a comment.

In D130689#3686718 , @thieta wrote:

> In D130689#3684399 , @h-vetinari 
> wrote:
>
>> It may be worth calling out that this is about C++17 core language and not 
>> the standard library?
>>
>> libstdcxx only finished C++17 support in GCC 12, and libcxx is still missing 
>> various pieces even today (much less for Clang 5).
>
> I will add a small line about this in the coding standards document.

Actually - never mind this is already well documented in the coding standards 
document:

  Unless otherwise documented, LLVM subprojects are written using standard C++17
  code and avoid unnecessary vendor-specific extensions.
  
  Nevertheless, we restrict ourselves to features which are available in the
  major toolchains supported as host compilers (see :doc:`GettingStarted` page,
  section `Software`).
  
  Each toolchain provides a good reference for what it accepts:
  
  * Clang: https://clang.llvm.org/cxx_status.html
  * GCC: https://gcc.gnu.org/projects/cxx-status.html#cxx17
  * MSVC: https://msdn.microsoft.com/en-us/library/hh567368.aspx

I feel that's good enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread H. Vetinari via Phabricator via lldb-commits 
h-vetinari added a comment.

From the text you quoted:

> LLVM subprojects are written using standard C++17

code and avoid unnecessary vendor-specific extensions.

I don't think the standard library can be called a vendor-specific extension, 
and so I think this still could/should be made clearer (even though the status 
links below would show upon inspection that there's no full support yet, but 
that's a bit too tucked away I feel).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Tobias Hieta via Phabricator via lldb-commits 
thieta added a comment.

In D130689#3686723 , @h-vetinari 
wrote:

> I don't think the standard library can be called a vendor-specific extension, 
> and so I think this still could/should be made clearer (even though the 
> status links below would show upon inspection that there's no full support 
> yet, but that's a bit too tucked away I feel).

For libstdc++ and libc++ there are also pages with status in a specific 
version. Maybe we should link those matrixes as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread H. Vetinari via Phabricator via lldb-commits 
h-vetinari added a comment.

My point boils down to: "written using standard C++17
code" does not sound at all like "core language, no stdlib", but very much like 
"core+stdlib".

This is also the first time this split becomes relevant AFAIK, because for 
moving to C++14, the stdlib was ready basically around the same time / compiler 
versions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D130689: [LLVM] Update C++ standard to 17

2022-07-29 Thread Mehdi AMINI via Phabricator via lldb-commits 
mehdi_amini added a comment.

In D130689#3686760 , @h-vetinari 
wrote:

> My point boils down to: "written using standard C++17
> code" does not sound at all like "core language, no stdlib", but very much 
> like "core+stdlib".

We're allowing C++17 library feature, this isn't covered by the "vendor 
extensions" part but by the following paragraph:

> Nevertheless, we restrict ourselves to features which are available in the 
> major toolchains supported as host compilers

This includes not only missing features in libstdc++ but also gcc and clang 
bugs/limitations that we'll have to work around.

> This is also the first time this split becomes relevant AFAIK

I don't : the migration to C++11 was done the same way, piecewise by making 
sure that when we start using a new feature (core or stdlib) it actually works 
on the stated minimum version of the toolchains we support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[Lldb-commits] [PATCH] D129131: Remove uses of llvm_shutdown

2022-07-29 Thread Michael Kruse via Phabricator via lldb-commits 
Meinersbur added inline comments.



Comment at: polly/lib/External/isl/interface/extract_interface.cc:590
delete Clang;
-   llvm::llvm_shutdown();
 

This file is imported from the upstream project 
(https://repo.or.cz/isl.git/blob/295cf91923295ca694e9e4433a0b818150421bee:/interface/extract_interface.cc#l590)
 and this change will be lost when synchronizing with it. However, this file is 
also not used within LLVM. I recommend to just keep as-is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129131

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

[Lldb-commits] [PATCH] D130795: [LLDB][NFC][Reliability] Fixes for int overflow and uninitialized state

2022-07-29 Thread Slava Gurevich via Phabricator via lldb-commits 
fixathon created this revision.
fixathon added reviewers: clayborg, aadsm, jingham, JDevlieghere.
Herald added a reviewer: shafik.
Herald added a project: All.
fixathon requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Fixing potential int overflow and uninitialized variables.
These were found by Coverity static code inspection.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130795

Files:
  lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
  lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp

Index: lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
===
--- lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
+++ lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
@@ -966,7 +966,7 @@
   // path jumps over the mid-function epilogue
 
   UnwindPlan::RowSP prologue_completed_row; // copy of prologue row of CFI
-  int prologue_completed_sp_bytes_offset_from_cfa; // The sp value before the
+  int prologue_completed_sp_bytes_offset_from_cfa = 0; // The sp value before the
// epilogue started executed
   bool prologue_completed_is_aligned = false;
   std::vector prologue_completed_saved_registers;
Index: lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -787,14 +787,14 @@
   //   }
 
   offset_t offset = 0;
-  int i = 0;
+  uint64_t i = 0;
   uint32_t version = extractor.GetU32(&offset);
   if (version == 1) {
 pending_item_refs.new_style = true;
 uint32_t item_size = extractor.GetU32(&offset);
 uint32_t start_of_array_offset = offset;
 while (offset < pending_items_pointer.items_buffer_size &&
-   static_cast(i) < pending_items_pointer.count) {
+   i < pending_items_pointer.count) {
   offset = start_of_array_offset + (i * item_size);
   ItemRefAndCodeAddress item;
   item.item_ref = extractor.GetAddress(&offset);
@@ -806,7 +806,7 @@
 offset = 0;
 pending_item_refs.new_style = false;
 while (offset < pending_items_pointer.items_buffer_size &&
-   static_cast(i) < pending_items_pointer.count) {
+   i < pending_items_pointer.count) {
   ItemRefAndCodeAddress item;
   item.item_ref = extractor.GetAddress(&offset);
   item.code_address = LLDB_INVALID_ADDRESS;
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -582,7 +582,7 @@
 dw_addr_t DWARFUnit::ReadAddressFromDebugAddrSection(uint32_t index) const {
   uint32_t index_size = GetAddressByteSize();
   dw_offset_t addr_base = GetAddrBase();
-  dw_addr_t offset = addr_base + index * index_size;
+  dw_addr_t offset = addr_base + static_cast(index) * index_size;
   const DWARFDataExtractor &data =
   m_dwarf.GetDWARFContext().getOrLoadAddrData();
   if (data.ValidOffsetForDataOfSize(offset, index_size))
@@ -1033,7 +1033,8 @@
   GetAddressByteSize(), [&](uint32_t index) {
 uint32_t index_size = GetAddressByteSize();
 dw_offset_t addr_base = GetAddrBase();
-lldb::offset_t offset = addr_base + index * index_size;
+lldb::offset_t offset =
+addr_base + static_cast(index) * index_size;
 return llvm::object::SectionedAddress{
 m_dwarf.GetDWARFContext().getOrLoadAddrData().GetMaxU64(
 &offset, index_size)};
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2731,7 +2731,7 @@
 
   uint64_t field_bit_offset = (attrs.member_byte_offset == UINT32_MAX
? 0
-   : (attrs.member_byte_offset * 8));
+   : (attrs.member_byte_offset * 8ULL));
 
   if (attrs.bit_size > 0) {
 FieldInfo this_field_info;
Index: lldb/source/Plugins/Process/Utility/NativeRegi

[Lldb-commits] [PATCH] D130796: [LLDB][NativePDB] Switch to use DWARFLocationList.

2022-07-29 Thread Zequan Wu via Phabricator via lldb-commits 
zequanwu created this revision.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Before, NativePDB uses scoped range as a workaround for value range, that 
causes 
problems (e.g. a variable's value can only have one range, but usually a 
variable's value is located at different address ranges, each at different 
locations, in optimized build). 
This patch let NativePDB switch to DWARFLocationList so a variable's value can 
be described at multiple non-overlapped address ranges and each range maps to a 
location.
Because overlapped address ranges sometimes exist 
 in codeview and 
DWARFLocationList doesn't allow overlapped ranges (otherwise internal binary 
search may fail), here's implementation strategy:

1. Always prefer whole value locations. Suppose a variable size is 8 bytes, one 
record is that for range [1, 5) first 4 bytes is at ecx, and another record is 
that for range [2, 8) the 8 bytes value is at rdx. This results: [1, 2) has 
first 4 bytes at ecx, [2, 8) has the whole value at rdx.
2. Always prefer the locations parsed earlier. Suppose first record is that for 
range [1, 5) value is at ecx, second record is that for range [2, 6) value is 
at eax. This results: [1, 5) -> ecx, [5, 6) -> eax.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130796

Files:
  lldb/include/lldb/Utility/RangeMap.h
  lldb/source/Expression/DWARFExpressionList.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/DWARFLocationExpression.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/DWARFLocationExpression.h
  lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.h
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/test/Shell/SymbolFile/NativePDB/Inputs/local-variables-registers.lldbinit
  lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test
  lldb/test/Shell/SymbolFile/NativePDB/local-variables-registers.s
  lldb/test/Shell/SymbolFile/NativePDB/subfield_register_simple_type.s

Index: lldb/test/Shell/SymbolFile/NativePDB/subfield_register_simple_type.s
===
--- lldb/test/Shell/SymbolFile/NativePDB/subfield_register_simple_type.s
+++ /dev/null
@@ -1,433 +0,0 @@
-# clang-format off
-# REQUIRES: lld, x86
-
-# RUN: %clang_cl --target=i386-windows-msvc -c /Fo%t.obj -- %s
-# RUN: lld-link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe /base:0x40
-# RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -s \
-# RUN: %p/Inputs/subfield_register_simple_type.lldbinit 2>&1 | FileCheck %s
-
-# This file is compiled from following source file:
-# clang-cl --target=i386-windows-msvc /Z7 /O1 -c /Fa a.cpp
-# __int64 __attribute__((optnone)) bar(__int64 x) { return x; };
-# __int64 foo(__int64 x) {
-#   return bar(x);
-# }
-#
-# int main(int argc, char** argv) {
-#   foo(argc);
-#   return 0;
-# }
-
-# FIXME: The following variable location have wrong register numbers due to
-# https://github.com/llvm/llvm-project/issues/53575. Fix them after resolving
-# the issue.
-
-# CHECK:  (lldb) image lookup -a 0x40102f -v
-# CHECK:  LineEntry: [0x00401026-0x00401039): C:\src\a.cpp:3
-# CHECK-NEXT: Variable: id = {{.*}}, name = "x", type = "int64_t", valid ranges = [0x0040102f-0x00401036), location = DW_OP_reg0 EAX, DW_OP_piece 0x4, DW_OP_reg2 EDX, DW_OP_piece 0x4, decl =
-
-	.text
-	.def	@feat.00;
-	.scl	3;
-	.type	0;
-	.endef
-	.globl	@feat.00
-.set @feat.00, 1
-	.intel_syntax noprefix
-	.file	"a.cpp"
-	.def	"?bar@@YA_J_J@Z";
-	.scl	2;
-	.type	32;
-	.endef
-	.section	.text,"xr",one_only,"?bar@@YA_J_J@Z"
-	.globl	"?bar@@YA_J_J@Z"# -- Begin function ?bar@@YA_J_J@Z
-	.p2align	4, 0x90
-"?bar@@YA_J_J@Z":   # @"?bar@@YA_J_J@Z"
-Lfunc_begin0:
-	.cv_func_id 0
-	.cv_file	1 "C:\\src\\a.cpp" "CB99424BC3DD1AB059A2DBC6841147F2" 1
-	.cv_loc	0 1 1 0 # a.cpp:1:0
-	.cv_fpo_proc	"?bar@@YA_J_J@Z" 8
-# %bb.0:# %entry
-	push	ebp
-	.cv_fpo_pushreg	ebp
-	mov	ebp, esp
-	.cv_fpo_setframe	ebp
-	and	esp, -8
-	.cv_fpo_stackalign	8
-	sub	esp, 8
-	.cv_fpo_stackalloc	8
-	.cv_fpo_endprologue
-	mov	eax, dword ptr [ebp + 8]
-	mov	ecx, dword ptr [ebp + 12]
-	mov	dword ptr [esp], eax
-	mov	dword ptr [esp + 4], ecx
-Ltmp0:
-	mov	eax, dword ptr [esp]
-	mov	edx, dword ptr [esp + 4]
-	mov	esp, ebp
-	pop	ebp
-	ret
-Ltmp1:
-	.cv_fpo_endproc
-Lfunc_end0:
-# -- End function
-	.def	"?foo@@YA_J_J@Z";
-	.scl	2;
-	.type	32;
-	.endef
-	.section	.text,"xr",one_only,"?foo@@YA_J_J@Z"
-	.globl	"?foo@@YA_J_J@Z"# -- Begin function ?foo@@YA_J_J@Z
-"?foo@@YA_J_J@Z":   # @"?foo@@YA_J_J@Z"
-Lfunc_begin1:
-	.cv_func_id 1
-	.cv_fpo_proc	"?foo@@YA_J_J@Z" 8
-# %bb.0:# %entry
-	#DEBUG_VALUE: fo

[Lldb-commits] [PATCH] D126614: [lldb] [gdb-remote] Client support for using the non-stop protocol

2022-07-29 Thread Michał Górny via Phabricator via lldb-commits 
mgorny updated this revision to Diff 448707.
mgorny marked an inline comment as done.
mgorny added a comment.

Thanks for the suggestions. I have to admit I don't necessarily like the 
`InterruptRead()` approach but given that the alternative involves major 
changes to how we read packets, I suppose it's a good enough solution (and big 
thanks for that suggestion!). All should be done now.


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

https://reviews.llvm.org/D126614

Files:
  lldb/packages/Python/lldbsuite/test/gdbclientutils.py
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td
  lldb/test/API/functionalities/gdb_remote_client/TestNonStop.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestNonStop.py
===
--- /dev/null
+++ lldb/test/API/functionalities/gdb_remote_client/TestNonStop.py
@@ -0,0 +1,120 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test.gdbclientutils import *
+from lldbsuite.test.lldbgdbclient import GDBRemoteTestBase
+
+
+class NonStopResponder(MockGDBServerResponder):
+def qSupported(self, client_supported):
+return "QNonStop+;" + super().qSupported(client_supported)
+
+def QNonStop(self, val):
+return "OK"
+
+def qfThreadInfo(self):
+return "mp10.10,p10.12"
+
+def qsThreadInfo(self):
+return "l"
+
+
+class TestNonStop(GDBRemoteTestBase):
+def test_run(self):
+class MyResponder(NonStopResponder):
+vStopped_counter = 0
+
+def vStopped(self):
+self.vStopped_counter += 1
+return ("OK" if self.vStopped_counter > 1
+else "T00thread:p10.10;")
+
+def cont(self):
+self.vStopped_counter = 0
+return ["OK", "%Stop:T02thread:p10.12;"]
+
+self.dbg.HandleCommand(
+"settings set plugin.process.gdb-remote.use-non-stop-protocol true")
+self.server.responder = MyResponder()
+target = self.dbg.CreateTarget("")
+process = self.connect(target)
+self.assertPacketLogContains(["QNonStop:1"])
+
+process.Continue()
+self.assertPacketLogContains(["vStopped"])
+self.assertEqual(process.GetSelectedThread().GetStopReason(),
+ lldb.eStopReasonSignal)
+self.assertEqual(process.GetSelectedThread().GetStopDescription(100),
+ "signal SIGINT")
+
+def test_stdio(self):
+class MyResponder(NonStopResponder):
+vStdio_counter = 0
+vStopped_counter = 0
+
+def vStdio(self):
+self.vStdio_counter += 1
+# intersperse notifications with replies for better testing
+return ("OK" if self.vStdio_counter > 1
+else ["%Stop:T02thread:p10.12;",
+  "O7365636f6e64206c696e650d0a"])
+
+def vStopped(self):
+self.vStopped_counter += 1
+return ("OK" if self.vStopped_counter > 1
+else "T00thread:p10.10;")
+
+def cont(self):
+self.vStopped_counter = 0
+self.vStdio_counter = 0
+return ["OK",
+"%Stdio:O6669727374206c696e650d0a",]
+
+self.dbg.HandleCommand(
+"settings set plugin.process.gdb-remote.use-non-stop-protocol true")
+self.server.responder = MyResponder()
+target = self.dbg.CreateTarget("")
+process = self.connect(target)
+self.assertPacketLogContains(["QNonStop:1"])
+
+process.Continue()
+self.assertPacketLogContains(["vStdio", "vStopped"])
+self.assertEqual(process.GetSelectedThread().GetStopReason(),
+ lldb.eStopReasonSignal)
+self.assertEqual(process.GetSelectedThread().GetStopDescription(100),
+ "signal SIGINT")
+
+def test_vCtrlC(self):
+class MyResponder(NonStopResponder):
+vStopped_counter = 0
+
+def vStopped(self):
+self.vStopped_counter += 1
+return ("OK" if self.vStopped_counter % 2 == 0
+else "T00thread:p10.10;")
+
+def cont(self):
+return ["OK"]
+
+def vCtrlC(self):
+

[Lldb-commits] [lldb] f7c961c - [LLDB][NFC][Reliability] Fixes for int overflow and uninitialized state

2022-07-29 Thread Slava Gurevich via lldb-commits 

Author: Slava Gurevich
Date: 2022-07-29T13:31:17-07:00
New Revision: f7c961cc6ba71c9d1fb845807e31b3a278d13c2f

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

LOG: [LLDB][NFC][Reliability] Fixes for int overflow and uninitialized state

Fixing potential int overflow and uninitialized variables.
These were found by Coverity static code inspection.

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

Added: 


Modified: 
lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp 
b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
index f86609f3c5c1c..80cee99ef0f8f 100644
--- a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -633,7 +633,7 @@ bool EmulateInstructionARM64::EmulateADDSUBImm(const 
uint32_t opcode) {
 imm = imm12;
 break;
   case 1:
-imm = imm12 << 12;
+imm = static_cast(imm12) << 12;
 break;
   default:
 return false; // UNDEFINED;

diff  --git 
a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp 
b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
index 222e4a2690e4f..f5525e3e3cb3d 100644
--- a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
+++ b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
@@ -18,7 +18,7 @@ using namespace lldb_private;
 static inline uint64_t GetStatusBit(uint32_t wp_index) {
   // DR6: ...
   // 3210 <- status bits for bp./wp. i; 1 if hit
-  return 1 << wp_index;
+  return 1ULL << wp_index;
 }
 
 // Returns mask/value for global enable bit of wp_index in DR7
@@ -27,14 +27,14 @@ static inline uint64_t GetEnableBit(uint32_t wp_index) {
   // 33221100 <- global/local enable for bp./wp.; 1 if enabled
   // we use global bits because NetBSD kernel does not preserve local
   // bits reliably; Linux seems fine with either
-  return 1 << (2 * wp_index + 1);
+  return 1ULL << (2 * wp_index + 1);
 }
 
 // Returns mask for both enable bits of wp_index in DR7
 static inline uint64_t GetBothEnableBitMask(uint32_t wp_index) {
   // DR7: ...GLGLGLGL
   // 33221100 <- global/local enable for bp./wp.; 1 if enabled
-  return 3 << (2 * wp_index + 1);
+  return 3ULL << (2 * wp_index + 1);
 }
 
 // Returns value for type bits of wp_index in DR7
@@ -47,7 +47,7 @@ static inline uint64_t GetWatchTypeBits(uint32_t watch_flags,
   // wp.: ...
   //
   // where T - type is 01 for write, 11 for r/w
-  return watch_flags << (16 + 4 * wp_index);
+  return static_cast(watch_flags) << (16 + 4 * wp_index);
 }
 
 // Returns value for size bits of wp_index in DR7
@@ -63,7 +63,8 @@ static inline uint64_t GetWatchSizeBits(uint32_t size, 
uint32_t wp_index) {
   // 01 for 2 bytes
   // 10 for 8 bytes
   // 11 for 4 bytes
-  return (size == 8 ? 0x2 : size - 1) << (18 + 4 * wp_index);
+  return static_cast(size == 8 ? 0x2 : size - 1)
+ << (18 + 4 * wp_index);
 }
 
 // Returns bitmask for all bits controlling wp_index in DR7

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 6de5ab44f26f7..b6407af18cfdf 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2731,7 +2731,7 @@ void DWARFASTParserClang::ParseSingleMember(
 
   uint64_t field_bit_offset = (attrs.member_byte_offset == UINT32_MAX
? 0
-   : (attrs.member_byte_offset * 8));
+   : (attrs.member_byte_offset * 8ULL));
 
   if (attrs.bit_size > 0) {
 FieldInfo this_field_info;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index 7b4a5d8eca3ed..dacf2f4110a4f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -582,7 +582,7 @@ void DWARFUnit::SetStrOffsetsBase(dw_offset_t 
str_offsets_base) {
 dw_addr_t DWARFUnit::ReadAddressFromDebugAddrSection(uint32_t index) const {
   uint32_t index_size = GetAddressByteSize();
   dw_offset_t addr_base = GetAddrBase();
-  dw_addr_t offset = addr_base + index *

[Lldb-commits] [PATCH] D130795: [LLDB][NFC][Reliability] Fixes for int overflow and uninitialized state

2022-07-29 Thread Slava Gurevich via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf7c961cc6ba7: [LLDB][NFC][Reliability] Fixes for int 
overflow and uninitialized state (authored by fixathon).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130795

Files:
  lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
  lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp

Index: lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
===
--- lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
+++ lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
@@ -966,7 +966,7 @@
   // path jumps over the mid-function epilogue
 
   UnwindPlan::RowSP prologue_completed_row; // copy of prologue row of CFI
-  int prologue_completed_sp_bytes_offset_from_cfa; // The sp value before the
+  int prologue_completed_sp_bytes_offset_from_cfa = 0; // The sp value before the
// epilogue started executed
   bool prologue_completed_is_aligned = false;
   std::vector prologue_completed_saved_registers;
Index: lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -787,14 +787,14 @@
   //   }
 
   offset_t offset = 0;
-  int i = 0;
+  uint64_t i = 0;
   uint32_t version = extractor.GetU32(&offset);
   if (version == 1) {
 pending_item_refs.new_style = true;
 uint32_t item_size = extractor.GetU32(&offset);
 uint32_t start_of_array_offset = offset;
 while (offset < pending_items_pointer.items_buffer_size &&
-   static_cast(i) < pending_items_pointer.count) {
+   i < pending_items_pointer.count) {
   offset = start_of_array_offset + (i * item_size);
   ItemRefAndCodeAddress item;
   item.item_ref = extractor.GetAddress(&offset);
@@ -806,7 +806,7 @@
 offset = 0;
 pending_item_refs.new_style = false;
 while (offset < pending_items_pointer.items_buffer_size &&
-   static_cast(i) < pending_items_pointer.count) {
+   i < pending_items_pointer.count) {
   ItemRefAndCodeAddress item;
   item.item_ref = extractor.GetAddress(&offset);
   item.code_address = LLDB_INVALID_ADDRESS;
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -582,7 +582,7 @@
 dw_addr_t DWARFUnit::ReadAddressFromDebugAddrSection(uint32_t index) const {
   uint32_t index_size = GetAddressByteSize();
   dw_offset_t addr_base = GetAddrBase();
-  dw_addr_t offset = addr_base + index * index_size;
+  dw_addr_t offset = addr_base + static_cast(index) * index_size;
   const DWARFDataExtractor &data =
   m_dwarf.GetDWARFContext().getOrLoadAddrData();
   if (data.ValidOffsetForDataOfSize(offset, index_size))
@@ -1033,7 +1033,8 @@
   GetAddressByteSize(), [&](uint32_t index) {
 uint32_t index_size = GetAddressByteSize();
 dw_offset_t addr_base = GetAddrBase();
-lldb::offset_t offset = addr_base + index * index_size;
+lldb::offset_t offset =
+addr_base + static_cast(index) * index_size;
 return llvm::object::SectionedAddress{
 m_dwarf.GetDWARFContext().getOrLoadAddrData().GetMaxU64(
 &offset, index_size)};
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2731,7 +2731,7 @@
 
   uint64_t field_bit_offset = (attrs.member_byte_offset == UINT32_MAX
? 0
-   : (attrs.member_byte_offset * 8));
+   : (attrs.member_byte_offset * 8ULL));
 
   if (attrs.bit_size > 0) {
 FieldInfo this_field_info;
Index: lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp
===
--- lldb/source/Plugins/P

[Lldb-commits] [PATCH] D130802: [LLDB][NFC] Fix memory/resource leak in FifoFiles

2022-07-29 Thread Slava Gurevich via Phabricator via lldb-commits 
fixathon created this revision.
fixathon added reviewers: clayborg, aadsm, jingham, JDevlieghere.
Herald added a project: All.
fixathon requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

The original code is creating a future object on the heap, but does not delete 
it in one of the return paths causing a leak.
Because the lifetime of the future object is the local scope of its containing 
function, there's no need for heap-based allocation in the first place.
This diff fixes the memory leak by moving the future object allocation to 
stack-based RAII. There's no change to the functionality or style of the code.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130802

Files:
  lldb/tools/lldb-vscode/FifoFiles.cpp


Index: lldb/tools/lldb-vscode/FifoFiles.cpp
===
--- lldb/tools/lldb-vscode/FifoFiles.cpp
+++ lldb/tools/lldb-vscode/FifoFiles.cpp
@@ -53,37 +53,34 @@
   // We use a pointer for this future, because otherwise its normal destructor
   // would wait for the getline to end, rendering the timeout useless.
   Optional line;
-  std::future *future =
-  new std::future(std::async(std::launch::async, [&]() {
-std::ifstream reader(m_fifo_file, std::ifstream::in);
-std::string buffer;
-std::getline(reader, buffer);
-if (!buffer.empty())
-  line = buffer;
-  }));
-  if (future->wait_for(timeout) == std::future_status::timeout || !line)
+  std::future future = std::async(std::launch::async, [&]() {
+std::ifstream reader(m_fifo_file, std::ifstream::in);
+std::string buffer;
+std::getline(reader, buffer);
+if (!buffer.empty())
+  line = buffer;
+  });
+  if (future.wait_for(timeout) == std::future_status::timeout || !line)
 return createStringError(inconvertibleErrorCode(),
  "Timed out trying to get messages from the " +
  m_other_endpoint_name);
-  delete future;
+
   return json::parse(*line);
 }
 
 Error FifoFileIO::SendJSON(const json::Value &json,
std::chrono::milliseconds timeout) {
   bool done = false;
-  std::future *future =
-  new std::future(std::async(std::launch::async, [&]() {
-std::ofstream writer(m_fifo_file, std::ofstream::out);
-writer << JSONToString(json) << std::endl;
-done = true;
-  }));
-  if (future->wait_for(timeout) == std::future_status::timeout || !done) {
+  std::future future = std::async(std::launch::async, [&]() {
+std::ofstream writer(m_fifo_file, std::ofstream::out);
+writer << JSONToString(json) << std::endl;
+done = true;
+  });
+  if (future.wait_for(timeout) == std::future_status::timeout || !done) {
 return createStringError(inconvertibleErrorCode(),
  "Timed out trying to send messages to the " +
  m_other_endpoint_name);
   }
-  delete future;
   return Error::success();
 }
 


Index: lldb/tools/lldb-vscode/FifoFiles.cpp
===
--- lldb/tools/lldb-vscode/FifoFiles.cpp
+++ lldb/tools/lldb-vscode/FifoFiles.cpp
@@ -53,37 +53,34 @@
   // We use a pointer for this future, because otherwise its normal destructor
   // would wait for the getline to end, rendering the timeout useless.
   Optional line;
-  std::future *future =
-  new std::future(std::async(std::launch::async, [&]() {
-std::ifstream reader(m_fifo_file, std::ifstream::in);
-std::string buffer;
-std::getline(reader, buffer);
-if (!buffer.empty())
-  line = buffer;
-  }));
-  if (future->wait_for(timeout) == std::future_status::timeout || !line)
+  std::future future = std::async(std::launch::async, [&]() {
+std::ifstream reader(m_fifo_file, std::ifstream::in);
+std::string buffer;
+std::getline(reader, buffer);
+if (!buffer.empty())
+  line = buffer;
+  });
+  if (future.wait_for(timeout) == std::future_status::timeout || !line)
 return createStringError(inconvertibleErrorCode(),
  "Timed out trying to get messages from the " +
  m_other_endpoint_name);
-  delete future;
+
   return json::parse(*line);
 }
 
 Error FifoFileIO::SendJSON(const json::Value &json,
std::chrono::milliseconds timeout) {
   bool done = false;
-  std::future *future =
-  new std::future(std::async(std::launch::async, [&]() {
-std::ofstream writer(m_fifo_file, std::ofstream::out);
-writer << JSONToString(json) << std::endl;
-done = true;
-  }));
-  if (future->wait_for(timeout) == std::future_status::timeout || !done) {
+  std::future future = std::async(std::launch::async, [&]() {
+std::ofstream writer(m_fifo_file, std::ofstream::out);
+writer << JSONToString(json) << std::endl;
+

[Lldb-commits] [PATCH] D130802: [LLDB][NFC] Fix memory/resource leak in FifoFiles

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



Comment at: lldb/tools/lldb-vscode/FifoFiles.cpp:53-54
 Expected FifoFileIO::ReadJSON(std::chrono::milliseconds timeout) {
   // We use a pointer for this future, because otherwise its normal destructor
   // would wait for the getline to end, rendering the timeout useless.
   Optional line;

This comment seems to indicate we need to use a pointer. Seems like this should 
either be rewritten to not try to use a future with a timeout or left as is?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130802

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

[Lldb-commits] [PATCH] D130803: [lldb] Allow SymbolTable regex search functions to match mangled name

2022-07-29 Thread Augusto Noronha via Phabricator via lldb-commits 
augusto2112 created this revision.
augusto2112 added reviewers: jingham, labath, aprantl.
Herald added a project: All.
augusto2112 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

It may be useful to search symbol table entries by mangled instead
of demangled names. Add this optional functionality in the SymbolTable
functions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130803

Files:
  lldb/include/lldb/Core/Module.h
  lldb/include/lldb/Symbol/Symtab.h
  lldb/source/Core/Module.cpp
  lldb/source/Symbol/Symtab.cpp

Index: lldb/source/Symbol/Symtab.cpp
===
--- lldb/source/Symbol/Symtab.cpp
+++ lldb/source/Symbol/Symtab.cpp
@@ -744,7 +744,7 @@
 
 uint32_t Symtab::AppendSymbolIndexesMatchingRegExAndType(
 const RegularExpression ®exp, SymbolType symbol_type,
-std::vector &indexes) {
+std::vector &indexes, bool match_against_demangled) {
   std::lock_guard guard(m_mutex);
 
   uint32_t prev_size = indexes.size();
@@ -753,7 +753,10 @@
   for (uint32_t i = 0; i < sym_end; i++) {
 if (symbol_type == eSymbolTypeAny ||
 m_symbols[i].GetType() == symbol_type) {
-  const char *name = m_symbols[i].GetName().AsCString();
+  const char *name =
+  match_against_demangled
+  ? m_symbols[i].GetMangled().GetMangledName().AsCString()
+  : m_symbols[i].GetName().AsCString();
   if (name) {
 if (regexp.Execute(name))
   indexes.push_back(i);
@@ -766,7 +769,7 @@
 uint32_t Symtab::AppendSymbolIndexesMatchingRegExAndType(
 const RegularExpression ®exp, SymbolType symbol_type,
 Debug symbol_debug_type, Visibility symbol_visibility,
-std::vector &indexes) {
+std::vector &indexes, bool match_against_demangled) {
   std::lock_guard guard(m_mutex);
 
   uint32_t prev_size = indexes.size();
@@ -778,7 +781,10 @@
   if (!CheckSymbolAtIndex(i, symbol_debug_type, symbol_visibility))
 continue;
 
-  const char *name = m_symbols[i].GetName().AsCString();
+  const char *name =
+  match_against_demangled
+  ? m_symbols[i].GetMangled().GetMangledName().AsCString()
+  : m_symbols[i].GetName().AsCString();
   if (name) {
 if (regexp.Execute(name))
   indexes.push_back(i);
@@ -847,11 +853,12 @@
 void Symtab::FindAllSymbolsMatchingRexExAndType(
 const RegularExpression ®ex, SymbolType symbol_type,
 Debug symbol_debug_type, Visibility symbol_visibility,
-std::vector &symbol_indexes) {
+std::vector &symbol_indexes, bool match_against_demangled) {
   std::lock_guard guard(m_mutex);
 
   AppendSymbolIndexesMatchingRegExAndType(regex, symbol_type, symbol_debug_type,
-  symbol_visibility, symbol_indexes);
+  symbol_visibility, symbol_indexes,
+  match_against_demangled);
 }
 
 Symbol *Symtab::FindFirstSymbolWithNameAndType(ConstString name,
Index: lldb/source/Core/Module.cpp
===
--- lldb/source/Core/Module.cpp
+++ lldb/source/Core/Module.cpp
@@ -1369,7 +1369,8 @@
 
 void Module::FindSymbolsMatchingRegExAndType(const RegularExpression ®ex,
  SymbolType symbol_type,
- SymbolContextList &sc_list) {
+ SymbolContextList &sc_list,
+ bool match_against_demangled) {
   // No need to protect this call using m_mutex all other method calls are
   // already thread safe.
   LLDB_SCOPED_TIMERF(
@@ -1379,7 +1380,7 @@
 std::vector symbol_indexes;
 symtab->FindAllSymbolsMatchingRexExAndType(
 regex, symbol_type, Symtab::eDebugAny, Symtab::eVisibilityAny,
-symbol_indexes);
+symbol_indexes, match_against_demangled);
 SymbolIndicesToSymbolContextList(symtab, symbol_indexes, sc_list);
   }
 }
Index: lldb/include/lldb/Symbol/Symtab.h
===
--- lldb/include/lldb/Symbol/Symtab.h
+++ lldb/include/lldb/Symbol/Symtab.h
@@ -89,14 +89,13 @@
   Debug symbol_debug_type,
   Visibility symbol_visibility,
   std::vector &matches);
-  uint32_t
-  AppendSymbolIndexesMatchingRegExAndType(const RegularExpression ®ex,
-  lldb::SymbolType symbol_type,
-  std::vector &indexes);
+  uint32_t AppendSymbolIndexesMatchingRegExAndType(
+  const RegularExpression ®ex, lldb::SymbolType symbol_type,
+  std::vector &indexes, bool match_against_demangled = false);
   uint32_t AppendSymbolIndexesMatchingRegExAndTy

[Lldb-commits] [PATCH] D130803: [lldb] Allow SymbolTable regex search functions to match mangled name

2022-07-29 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added a comment.

It sounds like it should be possible to test this with `lldb-test`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130803

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

[Lldb-commits] [PATCH] D130802: [LLDB][NFC] Fix memory/resource leak in FifoFiles

2022-07-29 Thread Slava Gurevich via Phabricator via lldb-commits 
fixathon added inline comments.



Comment at: lldb/tools/lldb-vscode/FifoFiles.cpp:53-54
 Expected FifoFileIO::ReadJSON(std::chrono::milliseconds timeout) {
   // We use a pointer for this future, because otherwise its normal destructor
   // would wait for the getline to end, rendering the timeout useless.
   Optional line;

clayborg wrote:
> This comment seems to indicate we need to use a pointer. Seems like this 
> should either be rewritten to not try to use a future with a timeout or left 
> as is?
Good catch. Looks like the original code aims to intentionally orphan the 
'future' object if it's blocked (possibly infinitely) in its destructor waiting 
for the executing thread to rejoin. This could happen if the workload uses 
blocking I/O calls like we have here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130802

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

[Lldb-commits] [PATCH] D130803: [lldb] Allow SymbolTable regex search functions to match mangled name

2022-07-29 Thread Augusto Noronha via Phabricator via lldb-commits 
augusto2112 added a comment.

@aprantl do you mean dumping this with `lldb-test`?  I'm not seeing a way to do 
this. If you're thinking about `symbols` that reads the symbol file not the 
symbol table.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130803

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

[Lldb-commits] [PATCH] D130805: Support a new kernel section in LLDB’s trace bundle schema

2022-07-29 Thread Sujin Park via Phabricator via lldb-commits 
persona0220 created this revision.
persona0220 added reviewers: wallace, jj10306.
Herald added a project: All.
persona0220 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Add a new "kernel" section with following schema.

  "kernel": {
"loadAddress"?: decimal | hex string | string decimal 
# This is optional. If it's not specified, use default address 
0x8100.
"file": string
# path to the kernel image
  }

Here's more details of the diff:

- If "kernel" section exist, it means current tracing mode is //KernelMode//.
- If tracing mode is //KernelMode//, the "processes" section must be empty and 
the "kernel" and "cpus" section must be provided. This is tested with 
`TestTraceLoad`.
- "kernel" section is parsed and turned into a new process with a single module 
which is the kernel image. The kernel process has N fake threads, one for each 
cpu.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130805

Files:
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTBundleLoader.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTBundleLoader.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTBundleSaver.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTConstants.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTJSONStructs.h
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/intelpt-kernel-trace/cores/45.intelpt_trace
  
lldb/test/API/commands/trace/intelpt-kernel-trace/cores/45.perf_context_switch_trace
  lldb/test/API/commands/trace/intelpt-kernel-trace/cores/51.intelpt_trace
  
lldb/test/API/commands/trace/intelpt-kernel-trace/cores/51.perf_context_switch_trace
  lldb/test/API/commands/trace/intelpt-kernel-trace/modules/m.out
  lldb/test/API/commands/trace/intelpt-kernel-trace/trace.json
  
lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_with_process.json
  lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_wo_cpus.json

Index: lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_wo_cpus.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_wo_cpus.json
@@ -0,0 +1,20 @@
+{
+  "cpuInfo": {
+"family": 6,
+"model": 85,
+"stepping": 4,
+"vendor": "GenuineIntel"
+  },
+  "processes": [
+  ],
+  "tscPerfZeroConversion": {
+"timeMult": 1076264588,
+"timeShift": 31,
+"timeZero": 18433473881008870804
+  },
+  "kernel": {
+"file": "modules/m.out",
+"loadAddress": 4194304
+  },
+  "type": "intel-pt"
+}
Index: lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_with_process.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-kernel-trace/trace_kernel_with_process.json
@@ -0,0 +1,53 @@
+{
+  "cpus": [
+{
+  "contextSwitchTrace": "cores/45.perf_context_switch_trace",
+  "id": 45,
+  "iptTrace": "cores/45.intelpt_trace"
+},
+{
+  "contextSwitchTrace": "cores/51.perf_context_switch_trace",
+  "id": 51,
+  "iptTrace": "cores/51.intelpt_trace"
+}
+  ],
+  "cpuInfo": {
+"family": 6,
+"model": 85,
+"stepping": 4,
+"vendor": "GenuineIntel"
+  },
+  "processes": [
+{
+  "modules": [
+{
+  "file": "modules/m.out",
+  "systemPath": "/tmp/m.out",
+  "loadAddress": 4194304,
+  "uuid": "AEFB0D59-233F-80FF-6D3C-4DED498534CF-11017B3B"
+}
+  ],
+  "pid": 3497234,
+  "threads": [
+{
+  "tid": 3497234
+},
+{
+  "tid": 3497496
+},
+{
+  "tid": 3497497
+}
+  ]
+}
+  ],
+  "tscPerfZeroConversion": {
+"timeMult": 1076264588,
+"timeShift": 31,
+"timeZero": 18433473881008870804
+  },
+  "type": "intel-pt",
+  "kernel": {
+"file": "modules/m.out"
+  }
+}
Index: lldb/test/API/commands/trace/intelpt-kernel-trace/trace.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-kernel-trace/trace.json
@@ -0,0 +1,32 @@
+{
+  "cpus": [
+{
+  "contextSwitchTrace": "cores/45.perf_context_switch_trace",
+  "id": 45,
+  "iptTrace": "cores/45.intelpt_trace"
+},
+{
+  "contextSwitchTrace": "cores/51.perf_context_switch_trace",
+  "id": 51,
+  "iptTrace": "cores/51.intelpt_trace"
+}
+  ],
+  "cpuInfo": {
+"family": 6,
+"model": 85,
+"stepping": 4,
+"vendor": "GenuineIntel"
+  },
+  "processes": [
+  ],
+  "tscPerfZeroConversion": {
+"timeMult": 1076264588,
+"timeShift": 31,
+"timeZero": 18433473881008870804
+  },
+  "kernel": {
+"file": "modules/m.out",

[Lldb-commits] [PATCH] D130813: Add ability for lldb to load binaries in a process/corefile given only a load address & no dynamic loader

2022-07-29 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda created this revision.
jasonmolenda added reviewers: labath, JDevlieghere.
jasonmolenda added a project: LLDB.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added a subscriber: lldb-commits.

I'm adding support for a firmware type environment, without any dynamic linker, 
where we may have more than one binary in memory and we'll only be given the 
load addresses of the binaries.

lldb already has support for loading a single binary given a UUID & address or 
slide.  It slowly grew to the point (my fault) where three different classes 
(ProcessGDBRemote, ProcessMachCore, ObjectFileMachO) had versions of code to 
find and load the correct binary at the correct address into the Target.  This 
would have been yet another variation added to all three places, so obviously 
the first thing to do was make a unified utility function to do this.  I chose 
a static method in the DynamicLoader base class, 
`LoadBinaryWithUUIDAndAddress()` which handles this new case, as well as most 
of the others.  I removed the other copies of code that were doing similar 
things from those three classes.

I thought of making this a static method in DynamicLoaderStatic.  I couldn't 
come up with a strong preference either way -- it's only a method you'll be 
calling when you don't have a DynamicLoader plugin, so maybe that is the best 
place for it.

I added a new key-value to qProcessInfo, binary-addresses, which is a base16 
array of addresses where binaries are.  When given no UUID, lldb will try to 
read the binary from memory and find the UUID in the in-memory load commands, 
then do the normal "find me a binary for this UUID" schemes, loading it into 
the Target.

lldb already has "main bin spec" and "load binary" LC_NOTEs that always needed 
a UUID until today; this code now handles the case where no UUID is supplied, 
but we have a load address.  I was a little unhappy to find that 
UUID::IsValid() returns true for an all-zeroes UUID which seems like it should 
probably return invalid?  The LC_NOTEs use all-zeroes to indicate "no uuid", 
whereas our UUID class uses "optional data exists".  I have a few checks in 
ObjectFileMachO where I check the uuid_t to see if it is all-zeros before I 
copy them in to the UUID object.

I tested the qProcessInfo load method manually with a hacked debugserver & lldb 
which had no DynamicLoaderMacOS plugin; anything less than that looks like a 
valid macOS debug session and it was difficult to fool lldb into using these 
correctly.

I wrote a fun test case for the corefile support where it builds three test 
binaries - an executable and two shared libraries - and a program that creates 
a corefile of those three binaries at their load addresses.  Then we can run 
lldb on the corefile and confirm it loads binaries already known to lldb, via 
dsymForUUID, or loads a memory image as a last resort.  It took a bit to get 
the corefile creator working correctly, but it's pretty cool.

One tiny oddity I noticed is that we've ended up with

  include/lldb/Target/DynamicLoader.h
  source/Core/DynamicLoader.cpp

I didn't look into which one was intended to be correct & fix it for now.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D130813

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Target/DynamicLoader.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/Makefile
  
lldb/test/API/macosx/lc-note/multiple-binary-corefile/TestMultipleBinaryCorefile.py
  
lldb/test/API/macosx/lc-note/multiple-binary-corefile/create-multibin-corefile.cpp
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/main.c
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/one.c
  lldb/test/API/macosx/lc-note/multiple-binary-corefile/two.c

Index: lldb/test/API/macosx/lc-note/multiple-binary-corefile/two.c
===
--- /dev/null
+++ lldb/test/API/macosx/lc-note/multiple-binary-corefile/two.c
@@ -0,0 +1 @@
+int two() { return 10; }
Index: lldb/test/API/macosx/lc-note/multiple-binary-corefile/one.c
===
--- /dev/null
+++ lldb/test/API/macosx/lc-note/multiple-binary-corefile/one.c
@@ -0,0 +1 @@
+int one() { return 5; }
Index: lldb/test/API/macosx/lc-note/multiple-binary-corefile/main.c
===
--- /dev/null
+++ lldb/test/API/macosx/lc-note/multiple-binary-corefile/main.c
@@ -0,0 +1,7 @@
+#include 
+int one();
+int two();
+int main() {
+  puts("this is the standalone binary test program");
+  return on

[Lldb-commits] [PATCH] D130795: [LLDB][NFC][Reliability] Fixes for int overflow and uninitialized state

2022-07-29 Thread Shafik Yaghmour via Phabricator via lldb-commits 
shafik added inline comments.



Comment at: 
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp:67
+  return static_cast(size == 8 ? 0x2 : size - 1)
+ << (18 + 4 * wp_index);
 }

So we know that `wp_index` is never greater than 11?



Comment at: 
lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.cpp:77
   // wp.: xxEE33221100
   return GetBothEnableBitMask(wp_index) | (0xF << (16 + 4 * wp_index));
 }

You did not update `0xF` to `0xFULL`  like you did the constants above. Was 
that on purpose?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130795

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

[Lldb-commits] [PATCH] D130686: [LLDB][RISCV] Add DWARF Registers

2022-07-29 Thread Emmmer S via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf47355864770: [LLDB][RISCV] Add DWARF Registers (authored by 
Emmmer).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130686

Files:
  lldb/source/Utility/RISCV_DWARF_Registers.h

Index: lldb/source/Utility/RISCV_DWARF_Registers.h
===
--- /dev/null
+++ lldb/source/Utility/RISCV_DWARF_Registers.h
@@ -0,0 +1,132 @@
+//===-- RISCV_DWARF_Registers.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_UTILITY_RISCV_DWARF_REGISTERS_H
+#define LLDB_SOURCE_UTILITY_RISCV_DWARF_REGISTERS_H
+
+#include "lldb/lldb-private.h"
+
+namespace riscv_dwarf {
+
+enum {
+  dwarf_gpr_x0 = 0,
+  dwarf_gpr_x1,
+  dwarf_gpr_x2,
+  dwarf_gpr_x3,
+  dwarf_gpr_x4,
+  dwarf_gpr_x5,
+  dwarf_gpr_x6,
+  dwarf_gpr_x7,
+  dwarf_gpr_x8,
+  dwarf_gpr_x9,
+  dwarf_gpr_x10,
+  dwarf_gpr_x11,
+  dwarf_gpr_x12,
+  dwarf_gpr_x13,
+  dwarf_gpr_x14,
+  dwarf_gpr_x15,
+  dwarf_gpr_x16,
+  dwarf_gpr_x17,
+  dwarf_gpr_x18,
+  dwarf_gpr_x19,
+  dwarf_gpr_x20,
+  dwarf_gpr_x21,
+  dwarf_gpr_x22,
+  dwarf_gpr_x23,
+  dwarf_gpr_x24,
+  dwarf_gpr_x25,
+  dwarf_gpr_x26,
+  dwarf_gpr_x27,
+  dwarf_gpr_x28,
+  dwarf_gpr_x29,
+  dwarf_gpr_x30,
+  dwarf_gpr_x31 = 31,
+
+  dwarf_fpr_f0 = 32,
+  dwarf_fpr_f1,
+  dwarf_fpr_f2,
+  dwarf_fpr_f3,
+  dwarf_fpr_f4,
+  dwarf_fpr_f5,
+  dwarf_fpr_f6,
+  dwarf_fpr_f7,
+  dwarf_fpr_f8,
+  dwarf_fpr_f9,
+  dwarf_fpr_f10,
+  dwarf_fpr_f11,
+  dwarf_fpr_f12,
+  dwarf_fpr_f13,
+  dwarf_fpr_f14,
+  dwarf_fpr_f15,
+  dwarf_fpr_f16,
+  dwarf_fpr_f17,
+  dwarf_fpr_f18,
+  dwarf_fpr_f19,
+  dwarf_fpr_f20,
+  dwarf_fpr_f21,
+  dwarf_fpr_f22,
+  dwarf_fpr_f23,
+  dwarf_fpr_f24,
+  dwarf_fpr_f25,
+  dwarf_fpr_f26,
+  dwarf_fpr_f27,
+  dwarf_fpr_f28,
+  dwarf_fpr_f29,
+  dwarf_fpr_f30,
+  dwarf_fpr_f31 = 63,
+
+  // alternate frame return column
+  dwarf_alt_fr_col = 64,
+
+  dwarf_v0 = 96,
+  dwarf_v1,
+  dwarf_v2,
+  dwarf_v3,
+  dwarf_v4,
+  dwarf_v5,
+  dwarf_v6,
+  dwarf_v7,
+  dwarf_v8,
+  dwarf_v9,
+  dwarf_v10,
+  dwarf_v11,
+  dwarf_v12,
+  dwarf_v13,
+  dwarf_v14,
+  dwarf_v15,
+  dwarf_v16,
+  dwarf_v17,
+  dwarf_v18,
+  dwarf_v19,
+  dwarf_v20,
+  dwarf_v21,
+  dwarf_v22,
+  dwarf_v23,
+  dwarf_v24,
+  dwarf_v25,
+  dwarf_v26,
+  dwarf_v27,
+  dwarf_v28,
+  dwarf_v29,
+  dwarf_v30,
+  dwarf_v31 = 127,
+  dwarf_first_csr = 4096,
+  dwarf_last_csr = 8191,
+
+  // register name alias
+  dwarf_gpr_ra = dwarf_gpr_x1,
+  dwarf_gpr_sp = dwarf_gpr_x2,
+  dwarf_gpr_fp = dwarf_gpr_x8,
+
+  // mock pc regnum
+  dwarf_gpr_pc = UINT32_MAX,
+};
+
+} // namespace riscv_dwarf
+
+#endif // LLDB_SOURCE_UTILITY_RISCV_DWARF_REGISTERS_H
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f473558 - [LLDB][RISCV] Add DWARF Registers

2022-07-29 Thread via lldb-commits 

Author: Emmmer
Date: 2022-07-30T12:05:55+08:00
New Revision: f473558647705a042de9d5ec96c23a21f2005bb1

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

LOG: [LLDB][RISCV] Add DWARF Registers

According to [RISC-V DWARF 
Specification](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-dwarf.adoc)
 add RISCV DWARF Registers.

Don't worry about the difference between riscv32 and riscv64, they just have 
different bytes of registers.

Reviewed By: DavidSpickett

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

Added: 
lldb/source/Utility/RISCV_DWARF_Registers.h

Modified: 


Removed: 




diff  --git a/lldb/source/Utility/RISCV_DWARF_Registers.h 
b/lldb/source/Utility/RISCV_DWARF_Registers.h
new file mode 100644
index 0..d543bf0a6b5b1
--- /dev/null
+++ b/lldb/source/Utility/RISCV_DWARF_Registers.h
@@ -0,0 +1,132 @@
+//===-- RISCV_DWARF_Registers.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_UTILITY_RISCV_DWARF_REGISTERS_H
+#define LLDB_SOURCE_UTILITY_RISCV_DWARF_REGISTERS_H
+
+#include "lldb/lldb-private.h"
+
+namespace riscv_dwarf {
+
+enum {
+  dwarf_gpr_x0 = 0,
+  dwarf_gpr_x1,
+  dwarf_gpr_x2,
+  dwarf_gpr_x3,
+  dwarf_gpr_x4,
+  dwarf_gpr_x5,
+  dwarf_gpr_x6,
+  dwarf_gpr_x7,
+  dwarf_gpr_x8,
+  dwarf_gpr_x9,
+  dwarf_gpr_x10,
+  dwarf_gpr_x11,
+  dwarf_gpr_x12,
+  dwarf_gpr_x13,
+  dwarf_gpr_x14,
+  dwarf_gpr_x15,
+  dwarf_gpr_x16,
+  dwarf_gpr_x17,
+  dwarf_gpr_x18,
+  dwarf_gpr_x19,
+  dwarf_gpr_x20,
+  dwarf_gpr_x21,
+  dwarf_gpr_x22,
+  dwarf_gpr_x23,
+  dwarf_gpr_x24,
+  dwarf_gpr_x25,
+  dwarf_gpr_x26,
+  dwarf_gpr_x27,
+  dwarf_gpr_x28,
+  dwarf_gpr_x29,
+  dwarf_gpr_x30,
+  dwarf_gpr_x31 = 31,
+
+  dwarf_fpr_f0 = 32,
+  dwarf_fpr_f1,
+  dwarf_fpr_f2,
+  dwarf_fpr_f3,
+  dwarf_fpr_f4,
+  dwarf_fpr_f5,
+  dwarf_fpr_f6,
+  dwarf_fpr_f7,
+  dwarf_fpr_f8,
+  dwarf_fpr_f9,
+  dwarf_fpr_f10,
+  dwarf_fpr_f11,
+  dwarf_fpr_f12,
+  dwarf_fpr_f13,
+  dwarf_fpr_f14,
+  dwarf_fpr_f15,
+  dwarf_fpr_f16,
+  dwarf_fpr_f17,
+  dwarf_fpr_f18,
+  dwarf_fpr_f19,
+  dwarf_fpr_f20,
+  dwarf_fpr_f21,
+  dwarf_fpr_f22,
+  dwarf_fpr_f23,
+  dwarf_fpr_f24,
+  dwarf_fpr_f25,
+  dwarf_fpr_f26,
+  dwarf_fpr_f27,
+  dwarf_fpr_f28,
+  dwarf_fpr_f29,
+  dwarf_fpr_f30,
+  dwarf_fpr_f31 = 63,
+
+  // alternate frame return column
+  dwarf_alt_fr_col = 64,
+
+  dwarf_v0 = 96,
+  dwarf_v1,
+  dwarf_v2,
+  dwarf_v3,
+  dwarf_v4,
+  dwarf_v5,
+  dwarf_v6,
+  dwarf_v7,
+  dwarf_v8,
+  dwarf_v9,
+  dwarf_v10,
+  dwarf_v11,
+  dwarf_v12,
+  dwarf_v13,
+  dwarf_v14,
+  dwarf_v15,
+  dwarf_v16,
+  dwarf_v17,
+  dwarf_v18,
+  dwarf_v19,
+  dwarf_v20,
+  dwarf_v21,
+  dwarf_v22,
+  dwarf_v23,
+  dwarf_v24,
+  dwarf_v25,
+  dwarf_v26,
+  dwarf_v27,
+  dwarf_v28,
+  dwarf_v29,
+  dwarf_v30,
+  dwarf_v31 = 127,
+  dwarf_first_csr = 4096,
+  dwarf_last_csr = 8191,
+
+  // register name alias
+  dwarf_gpr_ra = dwarf_gpr_x1,
+  dwarf_gpr_sp = dwarf_gpr_x2,
+  dwarf_gpr_fp = dwarf_gpr_x8,
+
+  // mock pc regnum
+  dwarf_gpr_pc = UINT32_MAX,
+};
+
+} // namespace riscv_dwarf
+
+#endif // LLDB_SOURCE_UTILITY_RISCV_DWARF_REGISTERS_H



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

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

2022-07-29 Thread Richard Trieu via Phabricator via lldb-commits 
rtrieu added inline comments.



Comment at: clang/lib/AST/QualTypeNames.cpp:455
+  if (const auto *UT = QT->getAs()) {
+return getFullyQualifiedType(UT->getUnderlyingType(), Ctx,
+ WithGlobalNsPrefix);

Moving this down here means when the ElaboratedType is stripped off, its 
Qualifers aren't preserved in the underlying type.  rGfb7fa27f92ca has a fix to 
reattach the discarded Qualifiers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

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