[Lldb-commits] [PATCH] D157497: feat: Migrate isArch16Bit

[Evgeniy Makarev via Phabricator via lldb-commits]

Pivnoy added a comment.
Herald added a subscriber: sunshaoce.

@bulbazord 
@MaskRay


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157497

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

[Lldb-commits] [PATCH] D157497: feat: Migrate isArch16Bit

[Nikita Popov via Phabricator via lldb-commits]

nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.
Herald added a subscriber: StephenFan.

This change looks strictly worse in isolation, the proposal on discourse did 
not reach consensus, and looking at the diagram in 
https://discourse.llvm.org/t/rfc-refactor-triple-related-classes/70410/11 there 
is zero chance that it is ever going to be accepted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157497

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

[Lldb-commits] [PATCH] D158034: [lldb] Fix data race in ThreadList

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

After this patch, python_api/run_locker/TestRunLocker.py becomes flaky. 
https://lab.llvm.org/buildbot/#/builders/68/builds/58456 is the first such 
failure, but there have been about a dozen failures since then. The backtraces 
on the buildbot page are fairly useless, but I was able to capture this 
backtrace locally:

  include/c++/v1/vector:1537: assertion __n < size() failed: vector[] index out 
of bounds
  Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH 
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
  0  0x55dd180146be llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 46
  1  0x55dd18014d6c
  2  0x7fea9b3ce1c0
  3  0x7fea9b236347 raise + 167
  4  0x7fea9b237797 abort + 247
  5  0x55dd18862597
  6  0x55dd124c4563 
lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadPc(std::__u::shared_ptr
 const&, unsigned long) + 275
  7  0x55dd124c42fc 
lldb_private::process_gdb_remote::ProcessGDBRemote::DoUpdateThreadList(lldb_private::ThreadList&,
 lldb_private::ThreadList&) + 748
  8  0x55dd129c8687 lldb_private::Process::UpdateThreadListIfNeeded() + 247
  9  0x55dd12a39797 lldb_private::ThreadList::FindThreadByID(unsigned long, 
bool) + 55
  10 0x55dd12a396db lldb_private::ThreadList::GetSelectedThread() + 43
  11 0x55dd129a8dea 
lldb_private::ExecutionContext::ExecutionContext(lldb_private::Target*, bool) + 
234
  12 0x7fea99840bf9 lldb::SBTarget::EvaluateExpression(char const*, 
lldb::SBExpressionOptions const&) + 281
  13 0x7fea99840a7b lldb::SBTarget::EvaluateExpression(char const*) + 187
  14 0x7fea9995eb77
  15 0x55dd185907cd
  16 0x55dd18545814 _PyObject_Call + 292
  17 0x55dd1865fecb _PyEval_EvalFrameDefault + 11515
  18 0x55dd1865cfa8 _PyEval_Vector + 184
  19 0x55dd18c3
  20 0x55dd18666906
  21 0x55dd1865e56f _PyEval_EvalFrameDefault + 5023
  22 0x55dd1865cfa8 _PyEval_Vector + 184
  23 0x55dd18c3
  24 0x55dd18666906
  25 0x55dd1865e56f _PyEval_EvalFrameDefault + 5023
  26 0x55dd1865cfa8 _PyEval_Vector + 184
  27 0x55dd1865fecb _PyEval_EvalFrameDefault + 11515
  28 0x55dd1865cfa8 _PyEval_Vector + 184
  

Given that the failure is in the `DoUpdateThreadList` function, I'm guessing 
that this patch removed/reduced some existing synchronization which prevented 
this code from executing concurrently with something else (I don't know what), 
although it's possible that the right fix (since updating the thread list while 
the process is running doesn't make sense) is to bail out of 
`EvaluateExpression` sooner (@jingham ?).

If you want to reproduce this, note that the bug reproduces relatively 
infrequently (~1% for me, though it seems to be a bit higher on the buildbot), 
so you may need to run it many times before you can catch it in action. The 
failing part is not always the same (e.g. sometimes it just hangs), but I 
expect the root cause to be the same. I've also confirmed that the failure rate 
of the test goes down to zero after reverting this patch.

Can you investigate (and possibly revert this patch in the mean time)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158034

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

[Lldb-commits] [PATCH] D158500: [lldb][AArch64] Linux corefile support for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett created this revision.
Herald added subscribers: ctetreau, kristof.beyls.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This adds the ability to read streaming SVE registers,
ZA, SVCR and SVG from core files.

Streaming SVE is in a new note NT_ARM_SSVE but otherwise
has the same format as SVE. So I've done the same as I
did for live processes and reused the existing SVE state
with an extra state for the mode variable.

ZA is in a note NT_ARM_ZA and again the handling matches
live processes. Except that it gets setup only once. A
disabled ZA reads as 0s as usual.

SVCR and SVG are pseudo registers, generated from the notes.

An important details is that the notes represent what
you would have got if you read from ptrace at the time of
the crash.

This means that for a corefile in non-streaming mode,
there is still an NT_ARM_SSVE note and we check the header
flags to tell if it is active. We cannot just say if you
have the note you're in streaming mode.

The kernel does not provide register values for the inactive
mode and even if it did, they would be undefined, so if we find
streaming state, we ignore the non-streaming state.

Same for ZA, a disabled ZA still has the header in the note.

The tests do not cover all combinations but enough different
vector lengths, modes and ZA states to be confident.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158500

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
  lldb/test/API/linux/aarch64/sme_core_file/TestAArch64LinuxSMECoreFile.py
  lldb/test/API/linux/aarch64/sme_core_file/core_0_16_32_1
  lldb/test/API/linux/aarch64/sme_core_file/core_0_32_16_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_16_32_0
  lldb/test/API/linux/aarch64/sme_core_file/core_1_32_16_1
  lldb/test/API/linux/aarch64/sme_core_file/main.c

Index: lldb/test/API/linux/aarch64/sme_core_file/main.c
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/sme_core_file/main.c
@@ -0,0 +1,140 @@
+// clang-format off
+// Compile with:
+// clang -target aarch64-unknown-linux-gnu main.c -o a.out -g -march=armv8.6-a+sve+sme
+//
+// For minimal corefile size, do this before running the program:
+// echo 0x20 > /proc/self/coredeump_filter
+//
+// Must be run on a system that has SVE and SME, including the smefa64
+// extension. Example command:
+// main 0 32 64 1
+//
+// This would not enter streaming mode, set non-streaming VL to 32
+// bytes, streaming VL to 64 bytes and enable ZA.
+// clang-format on
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef PR_SME_SET_VL
+#define PR_SME_SET_VL 63
+#endif
+
+#define SM_INST(c) asm volatile("msr s0_3_c4_c" #c "_3, xzr")
+#define SMSTART_SM SM_INST(3)
+#define SMSTART_ZA SM_INST(5)
+
+void set_sve_registers() {
+  // We assume the smefa64 feature is present, which allows ffr access
+  // in streaming mode.
+  asm volatile("setffr\n\t");
+  asm volatile("ptrue p0.b\n\t");
+  asm volatile("ptrue p1.h\n\t");
+  asm volatile("ptrue p2.s\n\t");
+  asm volatile("ptrue p3.d\n\t");
+  asm volatile("pfalse p4.b\n\t");
+  asm volatile("ptrue p5.b\n\t");
+  asm volatile("ptrue p6.h\n\t");
+  asm volatile("ptrue p7.s\n\t");
+  asm volatile("ptrue p8.d\n\t");
+  asm volatile("pfalse p9.b\n\t");
+  asm volatile("ptrue p10.b\n\t");
+  asm volatile("ptrue p11.h\n\t");
+  asm volatile("ptrue p12.s\n\t");
+  asm volatile("ptrue p13.d\n\t");
+  asm volatile("pfalse p14.b\n\t");
+  asm volatile("ptrue p15.b\n\t");
+
+  asm volatile("cpy  z0.b, p0/z, #1\n\t");
+  asm volatile("cpy  z1.b, p5/z, #2\n\t");
+  asm volatile("cpy  z2.b, p10/z, #3\n\t");
+  asm volatile("cpy  z3.b, p15/z, #4\n\t");
+  asm volatile("cpy  z4.b, p0/z, #5\n\t");
+  asm volatile("cpy  z5.b, p5/z, #6\n\t");
+  asm volatile("cpy  z6.b, p10/z, #7\n\t");
+  asm volatile("cpy  z7.b, p15/z, #8\n\t");
+  asm volatile("cpy  z8.b, p0/z, #9\n\t");
+  asm volatile("cpy  z9.b, p5/z, #10\n\t");
+  asm volatile("cpy  z10.b, p10/z, #11\n\t");
+  asm volatile("cpy  z11.b, p15/z, #12\n\t");
+  asm volatile("cpy  z12.b, p0/z, #13\n\t");
+  asm volatile("cpy  z13.b, p5/z, #14\n\t");
+  asm volatile("cpy  z14.b, p10/z, #15\n\t");
+  asm volatile("cpy  z15.b, p15/z, #16\n\t");
+  asm volatile("cpy  z16.b, p0/z, #17\n\t");
+  asm volatile("cpy  z17.b, p5/z, #18\n\t");
+  asm volatile("cpy  z18.b, p10/z, #19\n\t");
+  asm volatile("cpy  z19.b, p15/z, #20\n\t");
+  asm volatile("cpy  z20.b, p0/z, #21\n\t");
+  asm volatile("cpy  z21.b, p5/z, #22\n\t");
+  asm volatile("cpy  z22.b, p10/z, #23\n\t");
+  asm volatile("cpy  z23.b, p1

[Lldb-commits] [PATCH] D158500: [lldb][AArch64] Linux corefile support for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

I did have some code to verify the arguments were passed correctly to the 
program but it made each core file 200k so I don't think it's worth it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158500

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

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett created this revision.
Herald added subscribers: ctetreau, arphaman, kristof.beyls.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added projects: LLDB, LLVM.
Herald added subscribers: llvm-commits, lldb-commits.

This adds a release note for all the SME support now in LLDB
and a page where I have documented the user experience (for want
of a better term) when using SVE and SME.

This includes things like which mode transitions can or cannot
be triggered from within LLDB. I hope this will serve to A: document
what I've implemented and B: be a user's guide to these extensions.

(though it is not a design document, read the commits and code
for that sort of detail)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158506

Files:
  lldb/docs/index.rst
  lldb/docs/use/aarch64-linux.rst
  llvm/docs/ReleaseNotes.rst

Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -154,6 +154,10 @@
 * Methods in SBHostOS related to threads have had their implementations
   removed. These methods will return a value indicating failure.
 
+* LLDB now supports debugging the Scalable Matrix Extension (SME) on AArch64
+  Linux for both running processes and core files. For details refer to the
+  `AArch64 Linux documentation `_.
+
 Changes to Sanitizers
 -
 * HWASan now defaults to detecting use-after-scope bugs.
Index: lldb/docs/use/aarch64-linux.rst
===
--- /dev/null
+++ lldb/docs/use/aarch64-linux.rst
@@ -0,0 +1,190 @@
+Using LLDB On AArch64 Linux
+===
+
+This page explains the details of debugging certain AArch64 extensions using
+LLDB. If something is not mentioned here, it likely works as you would expect.
+
+This is not a replacement for ptrace and Linux Kernel documentation. This covers
+how LLDB has chosen to use those things and how that effects your experience as
+a user.
+
+Scalable Vector Extension (SVE)
+---
+
+See `here `__
+to learn about the extension and `here `__
+for the Linux Kernel's handling of it.
+
+In LLDB you will be able to see the following new registers:
+
+* ``z0-z31`` vector registers, each one has size equal to the vector length.
+* ``p0-p15`` predicate registers, each one containing 1 bit per byte in the vector
+  length. Making each one vector length / 8 sized.
+* ``ffr`` the first fault register, same size as a predicate register.
+* ``vg``, the vector length in "granules". Each granule is 8 bytes.
+
+.. code-block::
+
+   Scalable Vector Extension Registers:
+ vg = 0x0002
+ z0 = {0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 <...> }
+   <...>
+ p0 = {0xff 0xff}
+   <...>
+ffr = {0xff 0xff}
+
+The example above has a vector length of 16 bytes. Within LLDB you will always
+see "vg" as in the ``vg`` register, which is 2 in this case (8*2 = 16).
+Elsewhere you may see "vq" which is the vector length in quadwords (16 bytes)
+elsewhere. Where you see "vl", it is in bytes.
+
+Changing the Vector Length
+..
+
+While you can count the size of a P or Z register, it is intended that ``vg`` be
+used to find the current vector length.
+
+vg can be written. Writing the current vector length changes nothing. If you
+increase the vector length, the registers will likely be reset to 0. If you
+decrease it, LLDB will truncate the Z registers but everything else will be reset
+to 0.
+
+Generally you should not assume that SVE state after changing the vector length
+is in any way the same as it was previously. If you need to do it, do it before
+a function's first use of SVE.
+
+Z Register Presentation
+...
+
+LLDB makes no attempt to predict how an SVE Z register will be used. Even if the
+next SVE instruction (which may some distance away) would use, for example, 32
+bit elements, LLDB prints ``z0`` as single bytes.
+
+If you know what format you are going to use, give a format option::
+
+  (lldb) register read z0 -f uint32_t[]
+  z0 = {0x01010101 0x01010101 0x01010101 0x01010101}
+
+FPSIMD and SVE Modes
+
+
+Prior to the debugee's first use of SVE, it is in what the Linux Kernel terms
+SIMD mode. Only the FPU is being used. In this state LLDB will still show the
+SVE registers however the values are simply the FPU values zero extended up to
+the vector length.
+
+On first access to SVE, the process goes into SVE mode. Now the Z values are
+in the real Z registers.
+
+You can also trigger this with LLDB by writing to an SVE register. Note that
+there is no way to undo this change from w

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added reviewers: omjavaid, jasonmolenda.
DavidSpickett added a subscriber: jasonmolenda.
DavidSpickett added a comment.

@jasonmolenda you asked some good questions about all this before, any of those 
not answered by this doc? No need to look deeply into anything, just stuff that 
comes to mind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158506

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

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

And if one of those is why does lldb use `vg` with these strange units, I think 
"vg" the term Arm's Fast Models used and GDB adopted it. It's possible we could 
improve that later but for now it is what it is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158506

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

[Lldb-commits] [PATCH] D158514: [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef

[David Spickett via Phabricator via lldb-commits]

DavidSpickett created this revision.
Herald added subscribers: ctetreau, kristof.beyls.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This fixes a bug where writing vg during streaming mode
could prevent you reading za directly afterwards.

vg is invalided when the write happens. SVE is reconfigured
by reading back the new value from the remote. So far so good.

For SME, we read SVG which in some situations appeared to remain
valid but have a value of 0 (perhaps it had never been read).
This meant lldb expected the size of za to be 0 bytes and
rejected the remote's response.

To fix this, invalidate svg before reconfiguring. This ensures
that the value used is the latest one from the remote.

The bug may depend on timing, I could not find a consistent way
to trigger it. I originally found it when checking whether za
is disabled after a vg change, so I've added checks for that
to TestZAThreadedDynamic.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158514

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  
lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py


Index: 
lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
===
--- 
lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
+++ 
lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
@@ -125,11 +125,13 @@
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(4, 2)
 self.runCmd("register write vg 2")
+self.check_disabled_za_register(2)
 
 elif stopped_at_line_number == thY_break_line1:
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(2, 3)
 self.runCmd("register write vg 4")
+self.check_disabled_za_register(4)
 
 self.runCmd("thread continue 2")
 self.runCmd("thread continue 3")
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -798,6 +798,11 @@
   if (!reg_info)
 return;
 
+  // When vg is written it is automatically made invalid. Writing vg will also
+  // change svg if we're in streaming mode, so we must fetch the latest value
+  // from the remote.
+  SetRegisterIsValid(reg_info, false);
+
   uint64_t fail_value = LLDB_INVALID_ADDRESS;
   uint32_t svg_reg_num = reg_info->kinds[eRegisterKindLLDB];
   uint64_t svg_reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);


Index: lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
===
--- lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
+++ lldb/test/API/commands/register/register/aarch64_za_reg/za_dynamic_resize/TestZAThreadedDynamic.py
@@ -125,11 +125,13 @@
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(4, 2)
 self.runCmd("register write vg 2")
+self.check_disabled_za_register(2)
 
 elif stopped_at_line_number == thY_break_line1:
 self.runCmd("thread select %d" % (idx + 1))
 self.check_za_register(2, 3)
 self.runCmd("register write vg 4")
+self.check_disabled_za_register(4)
 
 self.runCmd("thread continue 2")
 self.runCmd("thread continue 3")
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -798,6 +798,11 @@
   if (!reg_info)
 return;
 
+  // When vg is written it is automatically made invalid. Writing vg will also
+  // change svg if we're in streaming mode, so we must fetch the latest value
+  // from the remote.
+  SetRegisterIsValid(reg_info, false);
+
   uint64_t fail_value = LLDB_INVALID_ADDRESS;
   uint32_t svg_reg_num = reg_info->kinds[eRegisterKindLLDB];
   uint64_t svg_reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D158514: [lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

And if you're wondering, ZA being disabled after a vector length change is 
expected. lldb is just reporting what the kernel does here. lldb-server will 
still give you back a block of 0s though and that's what was not shown in this 
situation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158514

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

[Lldb-commits] [PATCH] D151567: [Support] Report EISDIR when opening a directory

[Alison Zhang via Phabricator via lldb-commits]

azhan92 updated this revision to Diff 552353.
azhan92 retitled this revision from "[Support] Report EISDIR when opening a 
directory " to "[Support] Report EISDIR when opening a directory".
azhan92 added a comment.

Add unit test to verify patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151567

Files:
  llvm/lib/Support/Unix/Path.inc
  llvm/test/tools/llvm-symbolizer/input-file-err.test
  llvm/unittests/Support/CommandLineTest.cpp
  llvm/unittests/Support/Path.cpp


Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1287,6 +1287,22 @@
 }
 #endif
 
+TEST_F(FileSystemTest, OpenDirectoryAsFile) {
+  ASSERT_NO_ERROR(fs::create_directory(Twine(TestDirectory)));
+  ASSERT_EQ(fs::create_directory(Twine(TestDirectory), false),
+errc::file_exists);
+
+  int FD;
+  std::error_code EC;
+  EC = fs::openFileForRead(Twine(TestDirectory), FD);
+  ASSERT_EQ(EC, errc::is_a_directory);
+  EC = fs::openFileForWrite(Twine(TestDirectory), FD);
+  ASSERT_EQ(EC, errc::is_a_directory);
+
+  ASSERT_NO_ERROR(fs::remove_directories(Twine(TestDirectory)));
+  ::close(FD);
+}
+
 TEST_F(FileSystemTest, Remove) {
   SmallString<64> BaseDir;
   SmallString<64> Paths[4];
Index: llvm/unittests/Support/CommandLineTest.cpp
===
--- llvm/unittests/Support/CommandLineTest.cpp
+++ llvm/unittests/Support/CommandLineTest.cpp
@@ -1060,7 +1060,6 @@
   ASSERT_STREQ(Argv[0], "clang");
   ASSERT_STREQ(Argv[1], AFileExp.c_str());
 
-#if !defined(_AIX) && !defined(__MVS__)
   std::string ADirExp = std::string("@") + std::string(ADir.path());
   Argv = {"clang", ADirExp.c_str()};
   Res = cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
@@ -1068,7 +1067,6 @@
   ASSERT_EQ(2U, Argv.size());
   ASSERT_STREQ(Argv[0], "clang");
   ASSERT_STREQ(Argv[1], ADirExp.c_str());
-#endif
 }
 
 TEST(CommandLineTest, SetDefaultValue) {
Index: llvm/test/tools/llvm-symbolizer/input-file-err.test
===
--- llvm/test/tools/llvm-symbolizer/input-file-err.test
+++ llvm/test/tools/llvm-symbolizer/input-file-err.test
@@ -1,5 +1,3 @@
-Failing on AIX due to D153595. The test expects a different error message from 
the one given on AIX.
-XFAIL: target={{.*}}-aix{{.*}}
 RUN: not llvm-addr2line -e %p/Inputs/nonexistent 0x12 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONEXISTENT-A2L -DMSG=%errc_ENOENT
 RUN: not llvm-addr2line -e %p/Inputs/nonexistent 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONEXISTENT-A2L -DMSG=%errc_ENOENT
 CHECK-NONEXISTENT-A2L: llvm-addr2line{{.*}}: error: 
'{{.*}}Inputs/nonexistent': [[MSG]]
Index: llvm/lib/Support/Unix/Path.inc
===
--- llvm/lib/Support/Unix/Path.inc
+++ llvm/lib/Support/Unix/Path.inc
@@ -1019,6 +1019,13 @@
   auto Open = [&]() { return ::open(P.begin(), OpenFlags, Mode); };
   if ((ResultFD = sys::RetryAfterSignal(-1, Open)) < 0)
 return std::error_code(errno, std::generic_category());
+if (Access == FA_Read) {
+struct stat Status;
+if (fstat(ResultFD, &Status) == -1)
+  return std::error_code(errno, std::generic_category());
+if (S_ISDIR(Status.st_mode))
+  return make_error_code(errc::is_a_directory);
+}
 #ifndef O_CLOEXEC
   if (!(Flags & OF_ChildInherit)) {
 int r = fcntl(ResultFD, F_SETFD, FD_CLOEXEC);


Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1287,6 +1287,22 @@
 }
 #endif
 
+TEST_F(FileSystemTest, OpenDirectoryAsFile) {
+  ASSERT_NO_ERROR(fs::create_directory(Twine(TestDirectory)));
+  ASSERT_EQ(fs::create_directory(Twine(TestDirectory), false),
+errc::file_exists);
+
+  int FD;
+  std::error_code EC;
+  EC = fs::openFileForRead(Twine(TestDirectory), FD);
+  ASSERT_EQ(EC, errc::is_a_directory);
+  EC = fs::openFileForWrite(Twine(TestDirectory), FD);
+  ASSERT_EQ(EC, errc::is_a_directory);
+
+  ASSERT_NO_ERROR(fs::remove_directories(Twine(TestDirectory)));
+  ::close(FD);
+}
+
 TEST_F(FileSystemTest, Remove) {
   SmallString<64> BaseDir;
   SmallString<64> Paths[4];
Index: llvm/unittests/Support/CommandLineTest.cpp
===
--- llvm/unittests/Support/CommandLineTest.cpp
+++ llvm/unittests/Support/CommandLineTest.cpp
@@ -1060,7 +1060,6 @@
   ASSERT_STREQ(Argv[0], "clang");
   ASSERT_STREQ(Argv[1], AFileExp.c_str());
 
-#if !defined(_AIX) && !defined(__MVS__)
   std::string ADirExp = std::string("@") + std::string(ADir.path());
   Argv = {"clang", ADirExp.c_str()};
   Res = cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
@@ -1068,7 +1067,6 @@
   ASSERT_

[Lldb-commits] [PATCH] D158085: [LLDB][Docs] Update cross compilation docs and examples

[David Spickett via Phabricator via lldb-commits]

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

Link to CMake's cross compilation docs up front, as a fallback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158085

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -36,6 +36,8 @@
 * `Python `_
 * `SWIG `_ 4 or later.
 
+.. _Optional Dependencies:
+
 Optional Dependencies
 *
 
@@ -423,6 +425,10 @@
 Cross-compiling LLDB
 
 
+The advice presented here may not be complete or represent the best practices
+of CMake at this time. Please refer to `CMake's documentation `_
+if you have any doubts or want more in depth information.
+
 In order to debug remote targets running different architectures than your
 host, you will need to compile LLDB (or at least the server component) for the
 target. While the easiest solution is to just compile it locally on the target,
@@ -458,37 +464,56 @@
   -DLLDB_ENABLE_CURSES=0
   -DLLVM_ENABLE_TERMINFO=0
 
+(see :ref:`Optional Dependencies` for more)
+
 In this case you, will often not need anything other than the standard C and
 C++ libraries.
 
+If you find that CMake is finding a version of an optional dependency that
+for whatever reason doesn't work, consider simply disabling it if you don't
+know that you need it.
+
 Once all of the dependencies are in place, it's just a matter of configuring
 the build system with the locations and arguments of all the necessary tools.
 The most important cmake options here are:
 
-* ``CMAKE_CROSSCOMPILING`` : Set to 1 to enable cross-compilation.
-* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking
-  for libraries. You may need to set this to your architecture triple if you do
-  not specify all your include and library paths explicitly.
+* ``CMAKE_SYSTEM_NAME`` and ``CMAKE_SYSTEM_PROCESSOR``: This tells CMake what
+  the build target is and from this it will infer that you are cross compiling.
 * ``CMAKE_C_COMPILER``, ``CMAKE_CXX_COMPILER`` : C and C++ compilers for the
-  target architecture
+  target architecture.
 * ``CMAKE_C_FLAGS``, ``CMAKE_CXX_FLAGS`` : The flags for the C and C++ target
-  compilers. You may need to specify the exact target cpu and abi besides the
+  compilers. You may need to specify the exact target cpu and ABI besides the
   include paths for the target headers.
 * ``CMAKE_EXE_LINKER_FLAGS`` : The flags to be passed to the linker. Usually
   just a list of library search paths referencing the target libraries.
-* ``LLVM_TABLEGEN``, ``CLANG_TABLEGEN`` : Paths to llvm-tblgen and clang-tblgen
-  for the host architecture. If you already have built clang for the host, you
-  can point these variables to the executables in your build directory. If not,
-  you will need to build the llvm-tblgen and clang-tblgen host targets at
-  least.
 * ``LLVM_HOST_TRIPLE`` : The triple of the system that lldb (or lldb-server)
   will run on. Not setting this (or setting it incorrectly) can cause a lot of
   issues with remote debugging as a lot of the choices lldb makes depend on the
   triple reported by the remote platform.
+* ``LLVM_NATIVE_TOOL_DIR`` : Is a path to the llvm tools compiled for the host.
+  Any tool that must be run on the host during a cross build will be configured
+  from this path, so you do not need to set them all individually. If you are
+  doing a host build just for the purpose of a cross build, you will need it
+  to include at least ``llvm-tblgen``, ``clang-tblgen`` and ``lldb-tblgen``.
+  Please be aware that that list may grow over time.
+* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking
+  for libraries. You may need to set this to your architecture triple if you do
+  not specify all your include and library paths explicitly.
+
+To find the possible values of the ``CMAKE_*`` options, please refer to the
+CMake documentation.
 
 You can of course also specify the usual cmake options like
 ``CMAKE_BUILD_TYPE``, etc.
 
+For testing, you may want to set one of:
+
+* ``LLDB_TEST_COMPILER`` : The compiler used to build programs used
+  in the test suite. If you are also building clang, this will be used
+  but if you want to test remotely from the host, you should choose the
+  cross compiler you are using for the cross build.
+* ``LLDB_INCLUDE_TESTS=0`` : To disable the tests completely.
+
 Example 1: Cross-compiling for linux arm64 on Ubuntu host
 *
 
@@ -499,15 +524,19 @@
 
 ::
 
-  -DCMAKE_CROSSCOMPILING=1 \
-  -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
-  -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \
-  -DLL

[Lldb-commits] [PATCH] D158085: [LLDB][Docs] Update cross compilation docs and examples

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

> IMO it's usually the safest/most sustainable way to maintain 
> cross-compilation jobs.

Part of my unfamiliarity is that I don't cross compile more than one 
configuration at a time, so a another config file just to do what I already do 
always seems like work I don't need to do.

Anything else is liable to break eventually though, so I'll look into it for 
further updates to these instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158085

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

[Lldb-commits] [lldb] 1083ae2 - [LLDB][Docs] Update cross compilation docs and examples

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2023-08-22T15:53:47+01:00
New Revision: 1083ae23471839878153412d9c78955d9a7a29ac

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

LOG: [LLDB][Docs] Update cross compilation docs and examples

To address https://github.com/llvm/llvm-project/issues/64616, this change
does the following:

* Links back to the "Optional Dependencies" section from the cross
  compilation instructions where we talk about removing libraries.
  In the reported issue, the host libXML was found by CMAke somehow and
  disabling libXML fixed it, so this link should encourage users
  to try as many of those options as needed.

* Removes the use of CMAKE_CROSS_COMPILING. In older CMake versions
  it seems you could set this manually but now the advice is to set
  CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR then let CMake figure
  it out.

  There is also CMAKE_SYSTEM_VERSION which the docs say you have to
  set too, but I can only find examples of Windows and Android builds
  using this. It might be needed to "cross" compile from one version
  of AArch64 Linux to another, but I can't confirm that.

* Removes the tablegen tools paths in favour of DLLVM_NATIVE_TOOL_DIR.
  This one setting deals with all build tools in llvm that must be host
  versions.

* Updates the explanations of the common options and orders them
  in some rough order of relevance with the "might be needed" later.

Reviewed By: JDevlieghere, bulbazord

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

Added: 


Modified: 
lldb/docs/resources/build.rst

Removed: 




diff  --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index d4f7a558f87953..356f6d96eabcba 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -36,6 +36,8 @@ scripting support.
 * `Python `_
 * `SWIG `_ 4 or later.
 
+.. _Optional Dependencies:
+
 Optional Dependencies
 *
 
@@ -423,6 +425,10 @@ To build the documentation, configure with 
``LLVM_ENABLE_SPHINX=ON`` and build t
 Cross-compiling LLDB
 
 
+The advice presented here may not be complete or represent the best practices
+of CMake at this time. Please refer to `CMake's documentation 
`_
+if you have any doubts or want more in depth information.
+
 In order to debug remote targets running 
diff erent architectures than your
 host, you will need to compile LLDB (or at least the server component) for the
 target. While the easiest solution is to just compile it locally on the target,
@@ -458,37 +464,56 @@ further by passing the appropriate cmake options, such as:
   -DLLDB_ENABLE_CURSES=0
   -DLLVM_ENABLE_TERMINFO=0
 
+(see :ref:`Optional Dependencies` for more)
+
 In this case you, will often not need anything other than the standard C and
 C++ libraries.
 
+If you find that CMake is finding a version of an optional dependency that
+for whatever reason doesn't work, consider simply disabling it if you don't
+know that you need it.
+
 Once all of the dependencies are in place, it's just a matter of configuring
 the build system with the locations and arguments of all the necessary tools.
 The most important cmake options here are:
 
-* ``CMAKE_CROSSCOMPILING`` : Set to 1 to enable cross-compilation.
-* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking
-  for libraries. You may need to set this to your architecture triple if you do
-  not specify all your include and library paths explicitly.
+* ``CMAKE_SYSTEM_NAME`` and ``CMAKE_SYSTEM_PROCESSOR``: This tells CMake what
+  the build target is and from this it will infer that you are cross compiling.
 * ``CMAKE_C_COMPILER``, ``CMAKE_CXX_COMPILER`` : C and C++ compilers for the
-  target architecture
+  target architecture.
 * ``CMAKE_C_FLAGS``, ``CMAKE_CXX_FLAGS`` : The flags for the C and C++ target
-  compilers. You may need to specify the exact target cpu and abi besides the
+  compilers. You may need to specify the exact target cpu and ABI besides the
   include paths for the target headers.
 * ``CMAKE_EXE_LINKER_FLAGS`` : The flags to be passed to the linker. Usually
   just a list of library search paths referencing the target libraries.
-* ``LLVM_TABLEGEN``, ``CLANG_TABLEGEN`` : Paths to llvm-tblgen and clang-tblgen
-  for the host architecture. If you already have built clang for the host, you
-  can point these variables to the executables in your build directory. If not,
-  you will need to build the llvm-tblgen and clang-tblgen host targets at
-  least.
 * ``LLVM_HOST_TRIPLE`` : The triple of the system that lldb (or lldb-server)
   will run on. Not setting this (or setting it incorrectly) can cause a lot

[Lldb-commits] [PATCH] D158085: [LLDB][Docs] Update cross compilation docs and examples

[David Spickett via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1083ae234718: [LLDB][Docs] Update cross compilation docs and 
examples (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158085

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -36,6 +36,8 @@
 * `Python `_
 * `SWIG `_ 4 or later.
 
+.. _Optional Dependencies:
+
 Optional Dependencies
 *
 
@@ -423,6 +425,10 @@
 Cross-compiling LLDB
 
 
+The advice presented here may not be complete or represent the best practices
+of CMake at this time. Please refer to `CMake's documentation `_
+if you have any doubts or want more in depth information.
+
 In order to debug remote targets running different architectures than your
 host, you will need to compile LLDB (or at least the server component) for the
 target. While the easiest solution is to just compile it locally on the target,
@@ -458,37 +464,56 @@
   -DLLDB_ENABLE_CURSES=0
   -DLLVM_ENABLE_TERMINFO=0
 
+(see :ref:`Optional Dependencies` for more)
+
 In this case you, will often not need anything other than the standard C and
 C++ libraries.
 
+If you find that CMake is finding a version of an optional dependency that
+for whatever reason doesn't work, consider simply disabling it if you don't
+know that you need it.
+
 Once all of the dependencies are in place, it's just a matter of configuring
 the build system with the locations and arguments of all the necessary tools.
 The most important cmake options here are:
 
-* ``CMAKE_CROSSCOMPILING`` : Set to 1 to enable cross-compilation.
-* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking
-  for libraries. You may need to set this to your architecture triple if you do
-  not specify all your include and library paths explicitly.
+* ``CMAKE_SYSTEM_NAME`` and ``CMAKE_SYSTEM_PROCESSOR``: This tells CMake what
+  the build target is and from this it will infer that you are cross compiling.
 * ``CMAKE_C_COMPILER``, ``CMAKE_CXX_COMPILER`` : C and C++ compilers for the
-  target architecture
+  target architecture.
 * ``CMAKE_C_FLAGS``, ``CMAKE_CXX_FLAGS`` : The flags for the C and C++ target
-  compilers. You may need to specify the exact target cpu and abi besides the
+  compilers. You may need to specify the exact target cpu and ABI besides the
   include paths for the target headers.
 * ``CMAKE_EXE_LINKER_FLAGS`` : The flags to be passed to the linker. Usually
   just a list of library search paths referencing the target libraries.
-* ``LLVM_TABLEGEN``, ``CLANG_TABLEGEN`` : Paths to llvm-tblgen and clang-tblgen
-  for the host architecture. If you already have built clang for the host, you
-  can point these variables to the executables in your build directory. If not,
-  you will need to build the llvm-tblgen and clang-tblgen host targets at
-  least.
 * ``LLVM_HOST_TRIPLE`` : The triple of the system that lldb (or lldb-server)
   will run on. Not setting this (or setting it incorrectly) can cause a lot of
   issues with remote debugging as a lot of the choices lldb makes depend on the
   triple reported by the remote platform.
+* ``LLVM_NATIVE_TOOL_DIR`` : Is a path to the llvm tools compiled for the host.
+  Any tool that must be run on the host during a cross build will be configured
+  from this path, so you do not need to set them all individually. If you are
+  doing a host build just for the purpose of a cross build, you will need it
+  to include at least ``llvm-tblgen``, ``clang-tblgen`` and ``lldb-tblgen``.
+  Please be aware that that list may grow over time.
+* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking
+  for libraries. You may need to set this to your architecture triple if you do
+  not specify all your include and library paths explicitly.
+
+To find the possible values of the ``CMAKE_*`` options, please refer to the
+CMake documentation.
 
 You can of course also specify the usual cmake options like
 ``CMAKE_BUILD_TYPE``, etc.
 
+For testing, you may want to set one of:
+
+* ``LLDB_TEST_COMPILER`` : The compiler used to build programs used
+  in the test suite. If you are also building clang, this will be used
+  but if you want to test remotely from the host, you should choose the
+  cross compiler you are using for the cross build.
+* ``LLDB_INCLUDE_TESTS=0`` : To disable the tests completely.
+
 Example 1: Cross-compiling for linux arm64 on Ubuntu host
 *
 
@@ -499,15 +524,19 @@
 
 ::
 
-  -DCMAKE_CROSSCOMPILING=1 \
-  -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
-  -DCMAKE_

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

Feel free to completely ignore this, it's a pointless micro optimization.

I'm curious if it would be more efficient to write this as 

```
switch (name[0]) {
  case '?': return Mangled::eManglingSchemeMSVC;
  case '_': 
 switch(name[1]) {
...
 }
  case '$': 
 switch(name[1]) {
...
 }
```
or if it would actually be slower than the chain of "vector" comparisons we 
have right now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

aprantl wrote:
> Feel free to completely ignore this, it's a pointless micro optimization.
> 
> I'm curious if it would be more efficient to write this as 
> 
> ```
> switch (name[0]) {
>   case '?': return Mangled::eManglingSchemeMSVC;
>   case '_': 
>  switch(name[1]) {
> ...
>  }
>   case '$': 
>  switch(name[1]) {
> ...
>  }
> ```
> or if it would actually be slower than the chain of "vector" comparisons we 
> have right now?
I actually started writing a similar comment before discarding it. Even if this 
code is as hot as I expect it to be, I don't think it would outweigh the 
complexity and the potential for bugs. I really like how you can glance at the 
code and see the different mangling schemes and that's the first thing we'd 
lose. Anyway happy to be proven wrong too. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

JDevlieghere wrote:
> aprantl wrote:
> > Feel free to completely ignore this, it's a pointless micro optimization.
> > 
> > I'm curious if it would be more efficient to write this as 
> > 
> > ```
> > switch (name[0]) {
> >   case '?': return Mangled::eManglingSchemeMSVC;
> >   case '_': 
> >  switch(name[1]) {
> > ...
> >  }
> >   case '$': 
> >  switch(name[1]) {
> > ...
> >  }
> > ```
> > or if it would actually be slower than the chain of "vector" comparisons we 
> > have right now?
> I actually started writing a similar comment before discarding it. Even if 
> this code is as hot as I expect it to be, I don't think it would outweigh the 
> complexity and the potential for bugs. I really like how you can glance at 
> the code and see the different mangling schemes and that's the first thing 
> we'd lose. Anyway happy to be proven wrong too. 
Honestly the optimizer is pretty good at doing those, look at the IR: 
https://godbolt.org/z/PY3TeadbM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [lldb] a4dbdf4 - [LLDB] Allow expression evaluators to set arbitrary timeouts

[walter erquinigo via lldb-commits]

Author: walter erquinigo
Date: 2023-08-22T12:27:08-04:00
New Revision: a4dbdf4749938396dbf913478289fa426d8341ae

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

LOG: [LLDB] Allow expression evaluators to set arbitrary timeouts

https://github.com/llvm/llvm-project/commit/59237bb52c9483fce395428bfab5996eabe54ed0
 changed the behavior of the `SetTimeout` and `GetTimeout` methods of 
`EvaluateExpressionOptions`, which broke the Mojo REPL and related services 
(https://docs.modular.com/mojo/) because it relies on having infinite timeouts. 
That's a necessity because developers often use the REPL for executing 
extremely long-running numeric jobs. Having said that, 
`EvaluateExpressionOptions` shouldn't be that opinionated on this matter 
anyway. Instead, it should be the responsibility of the evaluator to define 
which timeout to use for each specific case.

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

Added: 


Modified: 
lldb/include/lldb/Target/Target.h

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f86bd3cb4ee55d..ed0ecbbddbf814 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -346,16 +346,9 @@ class EvaluateExpressionOptions {
 m_use_dynamic = dynamic;
   }
 
-  const Timeout &GetTimeout() const {
-assert(m_timeout && m_timeout->count() > 0);
-return m_timeout;
-  }
+  const Timeout &GetTimeout() const { return m_timeout; }
 
-  void SetTimeout(const Timeout &timeout) {
-// Disallow setting a non-zero timeout.
-if (timeout && timeout->count() > 0)
-  m_timeout = timeout;
-  }
+  void SetTimeout(const Timeout &timeout) { m_timeout = timeout; }
 
   const Timeout &GetOneThreadTimeout() const {
 return m_one_thread_timeout;



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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[walter erquinigo via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa4dbdf474993: [LLDB] Allow expression evaluators to set 
arbitrary timeouts (authored by wallace).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

Files:
  lldb/include/lldb/Target/Target.h


Index: lldb/include/lldb/Target/Target.h
===
--- lldb/include/lldb/Target/Target.h
+++ lldb/include/lldb/Target/Target.h
@@ -346,16 +346,9 @@
 m_use_dynamic = dynamic;
   }
 
-  const Timeout &GetTimeout() const {
-assert(m_timeout && m_timeout->count() > 0);
-return m_timeout;
-  }
+  const Timeout &GetTimeout() const { return m_timeout; }
 
-  void SetTimeout(const Timeout &timeout) {
-// Disallow setting a non-zero timeout.
-if (timeout && timeout->count() > 0)
-  m_timeout = timeout;
-  }
+  void SetTimeout(const Timeout &timeout) { m_timeout = timeout; }
 
   const Timeout &GetOneThreadTimeout() const {
 return m_one_thread_timeout;


Index: lldb/include/lldb/Target/Target.h
===
--- lldb/include/lldb/Target/Target.h
+++ lldb/include/lldb/Target/Target.h
@@ -346,16 +346,9 @@
 m_use_dynamic = dynamic;
   }
 
-  const Timeout &GetTimeout() const {
-assert(m_timeout && m_timeout->count() > 0);
-return m_timeout;
-  }
+  const Timeout &GetTimeout() const { return m_timeout; }
 
-  void SetTimeout(const Timeout &timeout) {
-// Disallow setting a non-zero timeout.
-if (timeout && timeout->count() > 0)
-  m_timeout = timeout;
-  }
+  void SetTimeout(const Timeout &timeout) { m_timeout = timeout; }
 
   const Timeout &GetOneThreadTimeout() const {
 return m_one_thread_timeout;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D158010: [lldb] Allow synthetic providers in C++ and fix linking problems

[walter erquinigo via Phabricator via lldb-commits]

wallace added inline comments.



Comment at: lldb/source/Commands/CommandObjectType.cpp:2174
 
-#if LLDB_ENABLE_PYTHON
-

electriclilies wrote:
> jingham wrote:
> > electriclilies wrote:
> > > rriddle wrote:
> > > > Why is this dropped?
> > > Walter and I want to use the synthetic types from C++, but right now it's 
> > > only supported in Python. The motivation behind this is to make it so 
> > > that we can actually use the synthetic types. 
> > Just to be clear.  There are already lots of synthetic child providers 
> > implemented in C++ in in lldb already (look for CXXSyntheticChildren 
> > constructors in CPlusPlusLanguage.cpp for instance).  
> > 
> > I think what you are saying is that you are removing the restriction that 
> > you have to BUILD lldb with Python in order to add C++ implemented 
> > summaries.  If that's indeed what you are saying, then this is fine, since 
> > that seems an odd restriction...
> > 
> > But it would be nice to have some kind of testing that this actually works, 
> > since I don't think any of our bots build lldb w/o Python.
> Yes that's exactly it! I agree it would be nice to have a test for it but I 
> don't know how to add it. 
@jingham , indeed, we couldn't add buildbot tests for this they all build with 
python support.

However, a good compromise is to enable all these commands except for the `add` 
ones, because they have the option to use python-defined extensions. `clear`, 
`delete`, `info` and `list` should be fine even without python scripting 
support.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158010

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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

fdeazeve wrote:
> JDevlieghere wrote:
> > aprantl wrote:
> > > Feel free to completely ignore this, it's a pointless micro optimization.
> > > 
> > > I'm curious if it would be more efficient to write this as 
> > > 
> > > ```
> > > switch (name[0]) {
> > >   case '?': return Mangled::eManglingSchemeMSVC;
> > >   case '_': 
> > >  switch(name[1]) {
> > > ...
> > >  }
> > >   case '$': 
> > >  switch(name[1]) {
> > > ...
> > >  }
> > > ```
> > > or if it would actually be slower than the chain of "vector" comparisons 
> > > we have right now?
> > I actually started writing a similar comment before discarding it. Even if 
> > this code is as hot as I expect it to be, I don't think it would outweigh 
> > the complexity and the potential for bugs. I really like how you can glance 
> > at the code and see the different mangling schemes and that's the first 
> > thing we'd lose. Anyway happy to be proven wrong too. 
> Honestly the optimizer is pretty good at doing those, look at the IR: 
> https://godbolt.org/z/PY3TeadbM
Sounds good, let's leave it!

Just trolling now: should we use some crazy #ifdef magic to flip the order 
based on the host platform, such the `?` comes first on windows and `$` comes 
first on Darwin?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

aprantl wrote:
> fdeazeve wrote:
> > JDevlieghere wrote:
> > > aprantl wrote:
> > > > Feel free to completely ignore this, it's a pointless micro 
> > > > optimization.
> > > > 
> > > > I'm curious if it would be more efficient to write this as 
> > > > 
> > > > ```
> > > > switch (name[0]) {
> > > >   case '?': return Mangled::eManglingSchemeMSVC;
> > > >   case '_': 
> > > >  switch(name[1]) {
> > > > ...
> > > >  }
> > > >   case '$': 
> > > >  switch(name[1]) {
> > > > ...
> > > >  }
> > > > ```
> > > > or if it would actually be slower than the chain of "vector" 
> > > > comparisons we have right now?
> > > I actually started writing a similar comment before discarding it. Even 
> > > if this code is as hot as I expect it to be, I don't think it would 
> > > outweigh the complexity and the potential for bugs. I really like how you 
> > > can glance at the code and see the different mangling schemes and that's 
> > > the first thing we'd lose. Anyway happy to be proven wrong too. 
> > Honestly the optimizer is pretty good at doing those, look at the IR: 
> > https://godbolt.org/z/PY3TeadbM
> Sounds good, let's leave it!
> 
> Just trolling now: should we use some crazy #ifdef magic to flip the order 
> based on the host platform, such the `?` comes first on windows and `$` comes 
> first on Darwin?
Did someone say tablegen? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Alex Langford via Phabricator via lldb-commits]

bulbazord marked 4 inline comments as done.
bulbazord added inline comments.



Comment at: lldb/source/Core/Mangled.cpp:61
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start

JDevlieghere wrote:
> aprantl wrote:
> > fdeazeve wrote:
> > > JDevlieghere wrote:
> > > > aprantl wrote:
> > > > > Feel free to completely ignore this, it's a pointless micro 
> > > > > optimization.
> > > > > 
> > > > > I'm curious if it would be more efficient to write this as 
> > > > > 
> > > > > ```
> > > > > switch (name[0]) {
> > > > >   case '?': return Mangled::eManglingSchemeMSVC;
> > > > >   case '_': 
> > > > >  switch(name[1]) {
> > > > > ...
> > > > >  }
> > > > >   case '$': 
> > > > >  switch(name[1]) {
> > > > > ...
> > > > >  }
> > > > > ```
> > > > > or if it would actually be slower than the chain of "vector" 
> > > > > comparisons we have right now?
> > > > I actually started writing a similar comment before discarding it. Even 
> > > > if this code is as hot as I expect it to be, I don't think it would 
> > > > outweigh the complexity and the potential for bugs. I really like how 
> > > > you can glance at the code and see the different mangling schemes and 
> > > > that's the first thing we'd lose. Anyway happy to be proven wrong too. 
> > > Honestly the optimizer is pretty good at doing those, look at the IR: 
> > > https://godbolt.org/z/PY3TeadbM
> > Sounds good, let's leave it!
> > 
> > Just trolling now: should we use some crazy #ifdef magic to flip the order 
> > based on the host platform, such the `?` comes first on windows and `$` 
> > comes first on Darwin?
> Did someone say tablegen? 
As much as I love micro-optimizations, let's do all of that in a follow-up. ;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

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

[Lldb-commits] [lldb] edc64d4 - [lldb] Add support for recognizing swift mangled names

[Alex Langford via lldb-commits]

Author: Alex Langford
Date: 2023-08-22T10:28:55-07:00
New Revision: edc64d49de92d33e709bcde1db5670ff430f5fad

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

LOG: [lldb] Add support for recognizing swift mangled names

Apple maintains a downstream fork of lldb in order to support swift
debugging. Much of that support is isolated to its own plugins, but some
of it is exposed in more generic code. I would like to take some of
the swift support we have downstream and move it upstream to llvm.org in
an effort to 1) reduce downstream maintenance burden, and 2) work
towards solidifying the process of adding new language support to lldb.

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

Added: 


Modified: 
lldb/include/lldb/Core/Mangled.h
lldb/source/Core/Mangled.cpp
lldb/unittests/Core/MangledTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Mangled.h 
b/lldb/include/lldb/Core/Mangled.h
index 9892426161e439..165e67838e84bc 100644
--- a/lldb/include/lldb/Core/Mangled.h
+++ b/lldb/include/lldb/Core/Mangled.h
@@ -43,7 +43,8 @@ class Mangled {
 eManglingSchemeMSVC,
 eManglingSchemeItanium,
 eManglingSchemeRustV0,
-eManglingSchemeD
+eManglingSchemeD,
+eManglingSchemeSwift,
   };
 
   /// Default constructor.

diff  --git a/lldb/source/Core/Mangled.cpp b/lldb/source/Core/Mangled.cpp
index d1973a9a8f7f63..4587119519e98e 100644
--- a/lldb/source/Core/Mangled.cpp
+++ b/lldb/source/Core/Mangled.cpp
@@ -58,6 +58,24 @@ Mangled::ManglingScheme 
Mangled::GetManglingScheme(llvm::StringRef const name) {
   if (name.startswith("___Z"))
 return Mangled::eManglingSchemeItanium;
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start
+  // with "_T". To minimize the chance of that happening, we only return true
+  // for select old-style swift mangled names. The known cases are ObjC classes
+  // and protocols. Classes are either prefixed with "_TtC" or "_TtGC".
+  // Protocols are prefixed with "_TtP".
+  if (name.startswith("_TtC") || name.startswith("_TtGC") ||
+  name.startswith("_TtP"))
+return Mangled::eManglingSchemeSwift;
+
+  // Swift 4.2 used "$S" and "_$S".
+  // Swift 5 and onward uses "$s" and "_$s".
+  // Swift also uses "@__swiftmacro_" as a prefix for mangling filenames.
+  if (name.startswith("$S") || name.startswith("_$S") ||
+  name.startswith("$s") || name.startswith("_$s") ||
+  name.startswith("@__swiftmacro_"))
+return Mangled::eManglingSchemeSwift;
+
   return Mangled::eManglingSchemeNone;
 }
 
@@ -228,6 +246,7 @@ bool Mangled::GetRichManglingInfo(RichManglingContext 
&context,
 
   case eManglingSchemeRustV0:
   case eManglingSchemeD:
+  case eManglingSchemeSwift:
 // Rich demangling scheme is not supported
 return false;
   }
@@ -265,6 +284,10 @@ ConstString Mangled::GetDemangledName() const {
   case eManglingSchemeD:
 demangled_name = GetDLangDemangledStr(m_mangled);
 break;
+  case eManglingSchemeSwift:
+// Demangling a swift name requires the swift compiler. This is
+// explicitly unsupported on llvm.org.
+break;
   case eManglingSchemeNone:
 llvm_unreachable("eManglingSchemeNone was handled already");
   }

diff  --git a/lldb/unittests/Core/MangledTest.cpp 
b/lldb/unittests/Core/MangledTest.cpp
index 284c2f21aadd61..4efc961d371d3f 100644
--- a/lldb/unittests/Core/MangledTest.cpp
+++ b/lldb/unittests/Core/MangledTest.cpp
@@ -89,6 +89,24 @@ TEST(MangledTest, EmptyForInvalidDLangName) {
   EXPECT_STREQ("", the_demangled.GetCString());
 }
 
+TEST(MangledTest, RecognizeSwiftMangledNames) {
+  llvm::StringRef valid_swift_mangled_names[] = {
+  "_TtC4main7MyClass",   // Mangled objc class name
+  "_TtP4main3Foo_",  // Mangld objc protocol name
+  "$s4main3BarCACycfC",  // Mangled name
+  "_$s4main3BarCACycfC", // Mangled name with leading underscore
+  "$S4main3BarCACycfC",  // Older swift mangled name
+  "_$S4main3BarCACycfC", // Older swift mangled name
+ // with leading underscore
+  // Mangled swift filename
+  "@__swiftmacro_4main16FunVariableNames9OptionSetfMm_.swift",
+  };
+
+  for (llvm::StringRef mangled : valid_swift_mangled_names)
+EXPECT_EQ(Mangled::GetManglingScheme(mangled),
+  Mangled::eManglingSchemeSwift);
+}
+
 TEST(MangledTest, BoolConversionOperator) {
   {
 ConstString MangledName("_ZN1a1b1cIiiiEEvm");



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

[Lldb-commits] [PATCH] D158470: [lldb] Add support for recognizing swift mangled names

[Alex Langford via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGedc64d49de92: [lldb] Add support for recognizing swift 
mangled names (authored by bulbazord).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158470

Files:
  lldb/include/lldb/Core/Mangled.h
  lldb/source/Core/Mangled.cpp
  lldb/unittests/Core/MangledTest.cpp


Index: lldb/unittests/Core/MangledTest.cpp
===
--- lldb/unittests/Core/MangledTest.cpp
+++ lldb/unittests/Core/MangledTest.cpp
@@ -89,6 +89,24 @@
   EXPECT_STREQ("", the_demangled.GetCString());
 }
 
+TEST(MangledTest, RecognizeSwiftMangledNames) {
+  llvm::StringRef valid_swift_mangled_names[] = {
+  "_TtC4main7MyClass",   // Mangled objc class name
+  "_TtP4main3Foo_",  // Mangld objc protocol name
+  "$s4main3BarCACycfC",  // Mangled name
+  "_$s4main3BarCACycfC", // Mangled name with leading underscore
+  "$S4main3BarCACycfC",  // Older swift mangled name
+  "_$S4main3BarCACycfC", // Older swift mangled name
+ // with leading underscore
+  // Mangled swift filename
+  "@__swiftmacro_4main16FunVariableNames9OptionSetfMm_.swift",
+  };
+
+  for (llvm::StringRef mangled : valid_swift_mangled_names)
+EXPECT_EQ(Mangled::GetManglingScheme(mangled),
+  Mangled::eManglingSchemeSwift);
+}
+
 TEST(MangledTest, BoolConversionOperator) {
   {
 ConstString MangledName("_ZN1a1b1cIiiiEEvm");
Index: lldb/source/Core/Mangled.cpp
===
--- lldb/source/Core/Mangled.cpp
+++ lldb/source/Core/Mangled.cpp
@@ -58,6 +58,24 @@
   if (name.startswith("___Z"))
 return Mangled::eManglingSchemeItanium;
 
+  // Swift's older style of mangling used "_T" as a mangling prefix. This can
+  // lead to false positives with other symbols that just so happen to start
+  // with "_T". To minimize the chance of that happening, we only return true
+  // for select old-style swift mangled names. The known cases are ObjC classes
+  // and protocols. Classes are either prefixed with "_TtC" or "_TtGC".
+  // Protocols are prefixed with "_TtP".
+  if (name.startswith("_TtC") || name.startswith("_TtGC") ||
+  name.startswith("_TtP"))
+return Mangled::eManglingSchemeSwift;
+
+  // Swift 4.2 used "$S" and "_$S".
+  // Swift 5 and onward uses "$s" and "_$s".
+  // Swift also uses "@__swiftmacro_" as a prefix for mangling filenames.
+  if (name.startswith("$S") || name.startswith("_$S") ||
+  name.startswith("$s") || name.startswith("_$s") ||
+  name.startswith("@__swiftmacro_"))
+return Mangled::eManglingSchemeSwift;
+
   return Mangled::eManglingSchemeNone;
 }
 
@@ -228,6 +246,7 @@
 
   case eManglingSchemeRustV0:
   case eManglingSchemeD:
+  case eManglingSchemeSwift:
 // Rich demangling scheme is not supported
 return false;
   }
@@ -265,6 +284,10 @@
   case eManglingSchemeD:
 demangled_name = GetDLangDemangledStr(m_mangled);
 break;
+  case eManglingSchemeSwift:
+// Demangling a swift name requires the swift compiler. This is
+// explicitly unsupported on llvm.org.
+break;
   case eManglingSchemeNone:
 llvm_unreachable("eManglingSchemeNone was handled already");
   }
Index: lldb/include/lldb/Core/Mangled.h
===
--- lldb/include/lldb/Core/Mangled.h
+++ lldb/include/lldb/Core/Mangled.h
@@ -43,7 +43,8 @@
 eManglingSchemeMSVC,
 eManglingSchemeItanium,
 eManglingSchemeRustV0,
-eManglingSchemeD
+eManglingSchemeD,
+eManglingSchemeSwift,
   };
 
   /// Default constructor.


Index: lldb/unittests/Core/MangledTest.cpp
===
--- lldb/unittests/Core/MangledTest.cpp
+++ lldb/unittests/Core/MangledTest.cpp
@@ -89,6 +89,24 @@
   EXPECT_STREQ("", the_demangled.GetCString());
 }
 
+TEST(MangledTest, RecognizeSwiftMangledNames) {
+  llvm::StringRef valid_swift_mangled_names[] = {
+  "_TtC4main7MyClass",   // Mangled objc class name
+  "_TtP4main3Foo_",  // Mangld objc protocol name
+  "$s4main3BarCACycfC",  // Mangled name
+  "_$s4main3BarCACycfC", // Mangled name with leading underscore
+  "$S4main3BarCACycfC",  // Older swift mangled name
+  "_$S4main3BarCACycfC", // Older swift mangled name
+ // with leading underscore
+  // Mangled swift filename
+  "@__swiftmacro_4main16FunVariableNames9OptionSetfMm_.swift",
+  };
+
+  for (llvm::StringRef mangled : valid_swift_mangled_names)
+EXPECT_EQ(Mangled::GetManglingScheme(mangled),
+  Mangled::eManglingSchemeSwift);
+}
+
 TEST(MangledTest, BoolConversionOperator) {
   {
 ConstString MangledName("_ZN1a1b1cIiiiEEvm");
Index: lldb/source/Core/Mangled.cpp
=

[Lldb-commits] [lldb] a43e23a - [lldb][NFCI] Silence warning about unhandled value eManglingSchemeSwift in switch statement

[Alex Langford via lldb-commits]

Author: Alex Langford
Date: 2023-08-22T10:35:36-07:00
New Revision: a43e23a2141f4fa78940844d810648ff8d40f474

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

LOG: [lldb][NFCI] Silence warning about unhandled value eManglingSchemeSwift in 
switch statement

For now, we don't handle swift names in Symtab.

Added: 


Modified: 
lldb/source/Symbol/Symtab.cpp

Removed: 




diff  --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index cf8732530c1ae2..6d94fe5031627b 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -256,6 +256,7 @@ static bool lldb_skip_name(llvm::StringRef mangled,
   case Mangled::eManglingSchemeMSVC:
   case Mangled::eManglingSchemeRustV0:
   case Mangled::eManglingSchemeD:
+  case Mangled::eManglingSchemeSwift:
 return false;
 
   // Don't try and demangle things we can't categorize.



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

[Lldb-commits] [lldb] ebff12d - [lldb][NFCI] Change return type of UnixSignals::GetSignalInfo

[Alex Langford via lldb-commits]

Author: Alex Langford
Date: 2023-08-22T10:54:06-07:00
New Revision: ebff12d675aa4db4ee8762c165a387a8d86dd0d5

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

LOG: [lldb][NFCI] Change return type of UnixSignals::GetSignalInfo

There's no reason for GetSignalInfo to return the signal name. All users
of this method only use the return value to determine if the method
succeeded in filling in the output parameters, so let's explicitly make
it a bool instead of a pointer.

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

Added: 


Modified: 
lldb/include/lldb/Target/UnixSignals.h
lldb/source/Target/UnixSignals.cpp
lldb/unittests/Signals/UnixSignalsTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/UnixSignals.h 
b/lldb/include/lldb/Target/UnixSignals.h
index 550a56a00060f2..b227b67e289229 100644
--- a/lldb/include/lldb/Target/UnixSignals.h
+++ b/lldb/include/lldb/Target/UnixSignals.h
@@ -43,8 +43,26 @@ class UnixSignals {
 
   int32_t GetSignalNumberFromName(const char *name) const;
 
-  const char *GetSignalInfo(int32_t signo, bool &should_suppress,
-bool &should_stop, bool &should_notify) const;
+  /// Gets the information for a particular signal
+  ///
+  /// GetSignalInfo takes a signal number and populates 3 out parameters
+  /// describing how lldb should react when a particular signal is received in
+  /// the inferior.
+  ///
+  /// \param[in] signo
+  ///   The signal number to get information about.
+  /// \param[out] should_suppress
+  ///   Should we suppress this signal?
+  /// \param[out] should_stop
+  ///   Should we stop if this signal is received?
+  /// \param[out] should_notify
+  ///   Should we notify the user if this signal is received?
+  ///
+  /// \return
+  ///   Returns a boolean value. Returns true if the out parameters were
+  ///   successfully populated, false otherwise.
+  bool GetSignalInfo(int32_t signo, bool &should_suppress, bool &should_stop,
+ bool &should_notify) const;
 
   bool GetShouldSuppress(int32_t signo) const;
 

diff  --git a/lldb/source/Target/UnixSignals.cpp 
b/lldb/source/Target/UnixSignals.cpp
index cf29f78c691c7d..b8e2a7675f7b24 100644
--- a/lldb/source/Target/UnixSignals.cpp
+++ b/lldb/source/Target/UnixSignals.cpp
@@ -237,19 +237,17 @@ int32_t UnixSignals::GetNextSignalNumber(int32_t 
current_signal) const {
   }
 }
 
-const char *UnixSignals::GetSignalInfo(int32_t signo, bool &should_suppress,
-   bool &should_stop,
-   bool &should_notify) const {
-  collection::const_iterator pos = m_signals.find(signo);
+bool UnixSignals::GetSignalInfo(int32_t signo, bool &should_suppress,
+bool &should_stop, bool &should_notify) const {
+  const auto pos = m_signals.find(signo);
   if (pos == m_signals.end())
-return nullptr;
-  else {
-const Signal &signal = pos->second;
-should_suppress = signal.m_suppress;
-should_stop = signal.m_stop;
-should_notify = signal.m_notify;
-return signal.m_name.AsCString("");
-  }
+return false;
+
+  const Signal &signal = pos->second;
+  should_suppress = signal.m_suppress;
+  should_stop = signal.m_stop;
+  should_notify = signal.m_notify;
+  return true;
 }
 
 bool UnixSignals::GetShouldSuppress(int signo) const {

diff  --git a/lldb/unittests/Signals/UnixSignalsTest.cpp 
b/lldb/unittests/Signals/UnixSignalsTest.cpp
index ab70c2ea218b78..acd39286922501 100644
--- a/lldb/unittests/Signals/UnixSignalsTest.cpp
+++ b/lldb/unittests/Signals/UnixSignalsTest.cpp
@@ -84,9 +84,9 @@ TEST(UnixSignalsTest, GetInfo) {
 
   bool should_suppress = false, should_stop = false, should_notify = false;
   int32_t signo = 4;
-  llvm::StringRef name =
+  bool success =
   signals.GetSignalInfo(signo, should_suppress, should_stop, 
should_notify);
-  EXPECT_EQ("SIG4", name);
+  ASSERT_TRUE(success);
   EXPECT_EQ(true, should_suppress);
   EXPECT_EQ(false, should_stop);
   EXPECT_EQ(true, should_notify);
@@ -94,7 +94,6 @@ TEST(UnixSignalsTest, GetInfo) {
   EXPECT_EQ(true, signals.GetShouldSuppress(signo));
   EXPECT_EQ(false, signals.GetShouldStop(signo));
   EXPECT_EQ(true, signals.GetShouldNotify(signo));
-  EXPECT_EQ(name, signals.GetSignalAsStringRef(signo));
 }
 
 TEST(UnixSignalsTest, GetAsStringRef) {



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

[Lldb-commits] [PATCH] D158457: [lldb][NFCI] Change return type of UnixSignals::GetSignalInfo

[Alex Langford via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGebff12d675aa: [lldb][NFCI] Change return type of 
UnixSignals::GetSignalInfo (authored by bulbazord).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158457

Files:
  lldb/include/lldb/Target/UnixSignals.h
  lldb/source/Target/UnixSignals.cpp
  lldb/unittests/Signals/UnixSignalsTest.cpp


Index: lldb/unittests/Signals/UnixSignalsTest.cpp
===
--- lldb/unittests/Signals/UnixSignalsTest.cpp
+++ lldb/unittests/Signals/UnixSignalsTest.cpp
@@ -84,9 +84,9 @@
 
   bool should_suppress = false, should_stop = false, should_notify = false;
   int32_t signo = 4;
-  llvm::StringRef name =
+  bool success =
   signals.GetSignalInfo(signo, should_suppress, should_stop, 
should_notify);
-  EXPECT_EQ("SIG4", name);
+  ASSERT_TRUE(success);
   EXPECT_EQ(true, should_suppress);
   EXPECT_EQ(false, should_stop);
   EXPECT_EQ(true, should_notify);
@@ -94,7 +94,6 @@
   EXPECT_EQ(true, signals.GetShouldSuppress(signo));
   EXPECT_EQ(false, signals.GetShouldStop(signo));
   EXPECT_EQ(true, signals.GetShouldNotify(signo));
-  EXPECT_EQ(name, signals.GetSignalAsStringRef(signo));
 }
 
 TEST(UnixSignalsTest, GetAsStringRef) {
Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -237,19 +237,17 @@
   }
 }
 
-const char *UnixSignals::GetSignalInfo(int32_t signo, bool &should_suppress,
-   bool &should_stop,
-   bool &should_notify) const {
-  collection::const_iterator pos = m_signals.find(signo);
+bool UnixSignals::GetSignalInfo(int32_t signo, bool &should_suppress,
+bool &should_stop, bool &should_notify) const {
+  const auto pos = m_signals.find(signo);
   if (pos == m_signals.end())
-return nullptr;
-  else {
-const Signal &signal = pos->second;
-should_suppress = signal.m_suppress;
-should_stop = signal.m_stop;
-should_notify = signal.m_notify;
-return signal.m_name.AsCString("");
-  }
+return false;
+
+  const Signal &signal = pos->second;
+  should_suppress = signal.m_suppress;
+  should_stop = signal.m_stop;
+  should_notify = signal.m_notify;
+  return true;
 }
 
 bool UnixSignals::GetShouldSuppress(int signo) const {
Index: lldb/include/lldb/Target/UnixSignals.h
===
--- lldb/include/lldb/Target/UnixSignals.h
+++ lldb/include/lldb/Target/UnixSignals.h
@@ -43,8 +43,26 @@
 
   int32_t GetSignalNumberFromName(const char *name) const;
 
-  const char *GetSignalInfo(int32_t signo, bool &should_suppress,
-bool &should_stop, bool &should_notify) const;
+  /// Gets the information for a particular signal
+  ///
+  /// GetSignalInfo takes a signal number and populates 3 out parameters
+  /// describing how lldb should react when a particular signal is received in
+  /// the inferior.
+  ///
+  /// \param[in] signo
+  ///   The signal number to get information about.
+  /// \param[out] should_suppress
+  ///   Should we suppress this signal?
+  /// \param[out] should_stop
+  ///   Should we stop if this signal is received?
+  /// \param[out] should_notify
+  ///   Should we notify the user if this signal is received?
+  ///
+  /// \return
+  ///   Returns a boolean value. Returns true if the out parameters were
+  ///   successfully populated, false otherwise.
+  bool GetSignalInfo(int32_t signo, bool &should_suppress, bool &should_stop,
+ bool &should_notify) const;
 
   bool GetShouldSuppress(int32_t signo) const;
 


Index: lldb/unittests/Signals/UnixSignalsTest.cpp
===
--- lldb/unittests/Signals/UnixSignalsTest.cpp
+++ lldb/unittests/Signals/UnixSignalsTest.cpp
@@ -84,9 +84,9 @@
 
   bool should_suppress = false, should_stop = false, should_notify = false;
   int32_t signo = 4;
-  llvm::StringRef name =
+  bool success =
   signals.GetSignalInfo(signo, should_suppress, should_stop, should_notify);
-  EXPECT_EQ("SIG4", name);
+  ASSERT_TRUE(success);
   EXPECT_EQ(true, should_suppress);
   EXPECT_EQ(false, should_stop);
   EXPECT_EQ(true, should_notify);
@@ -94,7 +94,6 @@
   EXPECT_EQ(true, signals.GetShouldSuppress(signo));
   EXPECT_EQ(false, signals.GetShouldStop(signo));
   EXPECT_EQ(true, signals.GetShouldNotify(signo));
-  EXPECT_EQ(name, signals.GetSignalAsStringRef(signo));
 }
 
 TEST(UnixSignalsTest, GetAsStringRef) {
Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -237,19 +237,17 @@
   }
 }
 
-const

[Lldb-commits] [lldb] 07afc41 - [lldb] Fix broken link in docs/index.rst

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2023-08-22T10:58:44-07:00
New Revision: 07afc41a2e6ab47097246f3f7c6e525a89ce1b9f

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

LOG: [lldb] Fix broken link in docs/index.rst

Added: 


Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index ae0261e15973da..80adf4135c37c9 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -25,8 +25,8 @@ Tutorial `_. For 
users already familiar
 with GDB there is a cheat sheet listing common tasks and their LLDB equivalent
 in the `GDB to LLDB command map `_.
 
-There are also multiple resources on how to script LLDB using Python:
-`use/python-reference`_ is a great starting point for that.
+There are also multiple resources on how to script LLDB using Python: the
+:doc:`use/python-reference` is a great starting point for that.
 
 Compiler Integration Benefits
 -



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

[Lldb-commits] [lldb] fef609d - Revert "[lldb] Fix data race in ThreadList"

[Augusto Noronha via lldb-commits]

Author: Augusto Noronha
Date: 2023-08-22T11:14:04-07:00
New Revision: fef609d2d1da573150121a6ee897e1d90f235eb1

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

LOG: Revert "[lldb] Fix data race in ThreadList"

This reverts commit bb90063249707e3ae081bfbd8e3512566abb7df6.

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/ThreadCollection.h
lldb/include/lldb/Target/ThreadList.h
lldb/source/Target/Process.cpp
lldb/source/Target/ThreadList.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 8e75ed85229429..44cda6d2ce1aad 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -2970,6 +2970,7 @@ void PruneThreadPlans();
   std::string m_exit_string; ///< A textual description of why a process 
exited.
   std::mutex m_exit_status_mutex; ///< Mutex so m_exit_status m_exit_string can
   ///be safely accessed from multiple threads
+  std::recursive_mutex m_thread_mutex;
   ThreadList m_thread_list_real; ///< The threads for this process as are known
  ///to the protocol we are debugging with
   ThreadList m_thread_list; ///< The threads for this process as the user will

diff  --git a/lldb/include/lldb/Target/ThreadCollection.h 
b/lldb/include/lldb/Target/ThreadCollection.h
index dc7d8f13eee037..29f5103e7eec7c 100644
--- a/lldb/include/lldb/Target/ThreadCollection.h
+++ b/lldb/include/lldb/Target/ThreadCollection.h
@@ -47,7 +47,7 @@ class ThreadCollection {
 return ThreadIterable(m_threads, GetMutex());
   }
 
-  std::recursive_mutex &GetMutex() const { return m_mutex; }
+  virtual std::recursive_mutex &GetMutex() const { return m_mutex; }
 
 protected:
   collection m_threads;

diff  --git a/lldb/include/lldb/Target/ThreadList.h 
b/lldb/include/lldb/Target/ThreadList.h
index 8aaff6e4cba0d4..6af04f8ffc3767 100644
--- a/lldb/include/lldb/Target/ThreadList.h
+++ b/lldb/include/lldb/Target/ThreadList.h
@@ -133,6 +133,8 @@ class ThreadList : public ThreadCollection {
 
   void SetStopID(uint32_t stop_id);
 
+  std::recursive_mutex &GetMutex() const override;
+
   void Update(ThreadList &rhs);
 
 protected:

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 57864a8a5da922..85ca0f6ab8d153 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -435,7 +435,7 @@ Process::Process(lldb::TargetSP target_sp, ListenerSP 
listener_sp,
   Listener::MakeListener("lldb.process.internal_state_listener")),
   m_mod_id(), m_process_unique_id(0), m_thread_index_id(0),
   m_thread_id_to_index_id_map(), m_exit_status(-1), m_exit_string(),
-  m_exit_status_mutex(), m_thread_list_real(this),
+  m_exit_status_mutex(), m_thread_mutex(), m_thread_list_real(this),
   m_thread_list(this), m_thread_plans(*this), m_extended_thread_list(this),
   m_extended_thread_stop_id(0), m_queue_list(this), 
m_queue_list_stop_id(0),
   m_notifications(), m_image_tokens(),
@@ -2455,7 +2455,7 @@ Process::WaitForProcessStopPrivate(EventSP &event_sp,
 }
 
 void Process::LoadOperatingSystemPlugin(bool flush) {
-  std::lock_guard guard(GetThreadList().GetMutex());
+  std::lock_guard guard(m_thread_mutex);
   if (flush)
 m_thread_list.Clear();
   m_os_up.reset(OperatingSystem::FindPlugin(this, nullptr));

diff  --git a/lldb/source/Target/ThreadList.cpp 
b/lldb/source/Target/ThreadList.cpp
index fc6cbd48cf8653..1ba0c435b993d3 100644
--- a/lldb/source/Target/ThreadList.cpp
+++ b/lldb/source/Target/ThreadList.cpp
@@ -736,8 +736,7 @@ void ThreadList::Update(ThreadList &rhs) {
   if (this != &rhs) {
 // Lock both mutexes to make sure neither side changes anyone on us while
 // the assignment occurs
-std::scoped_lock guard(
-GetMutex(), rhs.GetMutex());
+std::scoped_lock 
guard(GetMutex(), rhs.GetMutex());
 
 m_process = rhs.m_process;
 m_stop_id = rhs.m_stop_id;
@@ -782,6 +781,10 @@ void ThreadList::Flush() {
 (*pos)->Flush();
 }
 
+std::recursive_mutex &ThreadList::GetMutex() const {
+  return m_process->m_thread_mutex;
+}
+
 ThreadList::ExpressionExecutionThreadPusher::ExpressionExecutionThreadPusher(
 lldb::ThreadSP thread_sp)
 : m_thread_list(nullptr), m_tid(LLDB_INVALID_THREAD_ID) {



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

[Lldb-commits] [PATCH] D157497: feat: Migrate isArch16Bit

[Alex Langford via Phabricator via lldb-commits]

bulbazord requested changes to this revision.
bulbazord added a comment.

In D157497#4592330 , @Pivnoy wrote:

> At the moment, the TargetParser architecture is extensible. This complicates 
> the addition of new architectures, operating systems, and so on.
> In the main discussion, it was proposed to redesign the architecture of this 
> module in order to increase the possibility of adding new architectures, etc.
> The main idea of   the rework was to separate the Triple entity into a 
> data-class, and create a number of interfaces from components that would 
> include Triple, through the implementation of which it would be possible to 
> represent various data bindings of the components. At the moment, Triple is 
> overflowing with various methods that do not fully meet the ideas of OOP.
> Since the TargetParser module is quite large and has many dependencies 
> throughout the llvm-project, it was first of all supposed to remove these 
> methods from Triple, since they would not correspond to OOP ideas.
> This would help to gradually rid Triple of unnecessary dependencies, and 
> gradually change the architecture inside Triple, without breaking code of 
> another LLVM developers.

I'm still not sure how this would make things simpler. I'll be as specific is 
possible in what does not click for me.

There is an inherent complexity in parsing triples. Architectures can have 
variants and subvariants, compilers and other tools do different things for the 
same architecture and OS when there are different vendors, the environment can 
subtly change things like ABI, the list goes on. I don't think you're going to 
be able to wholesale reduce complexity here. The proposal you've laid out here 
is certainly very OOP-like (in some sense of the phrase "OOP") but you present 
your ideas under the assumption that this style of OOP is the ideal to strive 
for. Why is that? Why is this better than what exists today? Is it easier to 
debug? Is it more performant? Is it easier to maintain? I personally do not 
think it will be better than what already exists in any of those ways.

In the original discourse thread, you also made the argument that the potential 
performance overhead and binary size increase should be unnoticeable and that 
with modern machines we do not need to fight for each microsecond. Without any 
numbers for performance or size, this is not an argument I can accept. 
Knowingly adding a performance/size regression to your build tools without an 
appropriate tradeoff does not make sense to do.

If you want to do this, please provide a concrete argument for what benefit 
this brings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157497

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

[Lldb-commits] [lldb] 34f8469 - [lldb] Link back to the LLVM Project and Developer Policy from the docs

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2023-08-22T11:42:46-07:00
New Revision: 34f84697c37ece745e1c66a36b0faca281e8da3e

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

LOG: [lldb] Link back to the LLVM Project and Developer Policy from the docs

Add backlinks to the LLVM Project and the LLVM Developer Policy from the
docs. As suggested by Tanya on Discourse:
https://discourse.llvm.org/t/rfc-revamping-lldbs-website/72899.

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

Added: 


Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 80adf4135c37c9..e12a4569cfdd2e 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -6,8 +6,9 @@ The LLDB Debugger
 Welcome to the LLDB documentation!
 
 LLDB is a next generation, high-performance debugger. It is built as a set of
-reusable components which highly leverage existing libraries in the larger LLVM
-Project, such as the Clang expression parser and LLVM disassembler.
+reusable components which highly leverage existing libraries in the larger
+`LLVM Project `_, such as the Clang expression parser and
+LLVM disassembler.
 
 LLDB is the default debugger in Xcode on macOS and supports debugging C,
 Objective-C and C++ on the desktop and iOS devices and simulator.
@@ -163,5 +164,6 @@ interesting areas to contribute to lldb.
Source Code 
Releases 
Discussion Forums 
+   Developer Policy 
Bug Reports 
Code Reviews 



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

[Lldb-commits] [PATCH] D158467: [lldb] Link back to the LLVM Project and Developer Policy from the docs

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG34f84697c37e: [lldb] Link back to the LLVM Project and 
Developer Policy from the docs (authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158467

Files:
  lldb/docs/index.rst


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -6,8 +6,9 @@
 Welcome to the LLDB documentation!
 
 LLDB is a next generation, high-performance debugger. It is built as a set of
-reusable components which highly leverage existing libraries in the larger LLVM
-Project, such as the Clang expression parser and LLVM disassembler.
+reusable components which highly leverage existing libraries in the larger
+`LLVM Project `_, such as the Clang expression parser and
+LLVM disassembler.
 
 LLDB is the default debugger in Xcode on macOS and supports debugging C,
 Objective-C and C++ on the desktop and iOS devices and simulator.
@@ -163,5 +164,6 @@
Source Code 
Releases 
Discussion Forums 
+   Developer Policy 
Bug Reports 
Code Reviews 


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -6,8 +6,9 @@
 Welcome to the LLDB documentation!
 
 LLDB is a next generation, high-performance debugger. It is built as a set of
-reusable components which highly leverage existing libraries in the larger LLVM
-Project, such as the Clang expression parser and LLVM disassembler.
+reusable components which highly leverage existing libraries in the larger
+`LLVM Project `_, such as the Clang expression parser and
+LLVM disassembler.
 
 LLDB is the default debugger in Xcode on macOS and supports debugging C,
 Objective-C and C++ on the desktop and iOS devices and simulator.
@@ -163,5 +164,6 @@
Source Code 
Releases 
Discussion Forums 
+   Developer Policy 
Bug Reports 
Code Reviews 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 523110d - Add support for llvm::MCInstPrinter::setPrintBranchImmAsAddress

[Ted Woodward via lldb-commits]

Author: Ted Woodward
Date: 2023-08-22T14:16:14-05:00
New Revision: 523110d654a286607790e7637da6be312de3a7c7

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

LOG: Add support for llvm::MCInstPrinter::setPrintBranchImmAsAddress

llvm::MCInstPrinter has an option, controlled by setPrintBranchImmAsAddress,
to print branch targets as immediate addresses instead of offsets.
Turn this on in lldb, so targets that support this flag will print addresses
instead of offsets.

This requires the address of the instruction be provided, but fortunately
it's calculated right before the call to PrintMCInst.

Reviewed By: jasonmolenda, DavidSpickett

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

Added: 


Modified: 
lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp 
b/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
index b4fdcbd783570a..2e0e8e8cf7d36c 100644
--- a/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
+++ b/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
@@ -60,8 +60,8 @@ class DisassemblerLLVMC::MCDisasmInstance {
 
   uint64_t GetMCInst(const uint8_t *opcode_data, size_t opcode_data_len,
  lldb::addr_t pc, llvm::MCInst &mc_inst) const;
-  void PrintMCInst(llvm::MCInst &mc_inst, std::string &inst_string,
-   std::string &comments_string);
+  void PrintMCInst(llvm::MCInst &mc_inst, lldb::addr_t pc,
+   std::string &inst_string, std::string &comments_string);
   void SetStyle(bool use_hex_immed, HexImmediateStyle hex_style);
   bool CanBranch(llvm::MCInst &mc_inst) const;
   bool HasDelaySlot(llvm::MCInst &mc_inst) const;
@@ -607,7 +607,7 @@ class InstructionLLVMC : public lldb_private::Instruction {
 
 if (inst_size > 0) {
   mc_disasm_ptr->SetStyle(use_hex_immediates, hex_style);
-  mc_disasm_ptr->PrintMCInst(inst, out_string, comment_string);
+  mc_disasm_ptr->PrintMCInst(inst, pc, out_string, comment_string);
 
   if (!comment_string.empty()) {
 AppendComment(comment_string);
@@ -1290,6 +1290,8 @@ DisassemblerLLVMC::MCDisasmInstance::Create(const char 
*triple, const char *cpu,
   if (!instr_printer_up)
 return Instance();
 
+  instr_printer_up->setPrintBranchImmAsAddress(true);
+
   // Not all targets may have registered createMCInstrAnalysis().
   std::unique_ptr instr_analysis_up(
   curr_target->createMCInstrAnalysis(instr_info_up.get()));
@@ -1337,13 +1339,13 @@ uint64_t DisassemblerLLVMC::MCDisasmInstance::GetMCInst(
 }
 
 void DisassemblerLLVMC::MCDisasmInstance::PrintMCInst(
-llvm::MCInst &mc_inst, std::string &inst_string,
+llvm::MCInst &mc_inst, lldb::addr_t pc, std::string &inst_string,
 std::string &comments_string) {
   llvm::raw_string_ostream inst_stream(inst_string);
   llvm::raw_string_ostream comments_stream(comments_string);
 
   m_instr_printer_up->setCommentStream(comments_stream);
-  m_instr_printer_up->printInst(&mc_inst, 0, llvm::StringRef(),
+  m_instr_printer_up->printInst(&mc_inst, pc, llvm::StringRef(),
 *m_subtarget_info_up, inst_stream);
   m_instr_printer_up->setCommentStream(llvm::nulls());
   comments_stream.flush();



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

[Lldb-commits] [PATCH] D155107: Add support for llvm::MCInstPrinter::setPrintBranchImmAsAddress

[Ted Woodward via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG523110d654a2: Add support for 
llvm::MCInstPrinter::setPrintBranchImmAsAddress (authored by ted).

Changed prior to commit:
  https://reviews.llvm.org/D155107?vs=539679&id=552465#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155107

Files:
  lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp


Index: lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
===
--- lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
+++ lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
@@ -60,8 +60,8 @@
 
   uint64_t GetMCInst(const uint8_t *opcode_data, size_t opcode_data_len,
  lldb::addr_t pc, llvm::MCInst &mc_inst) const;
-  void PrintMCInst(llvm::MCInst &mc_inst, std::string &inst_string,
-   std::string &comments_string);
+  void PrintMCInst(llvm::MCInst &mc_inst, lldb::addr_t pc,
+   std::string &inst_string, std::string &comments_string);
   void SetStyle(bool use_hex_immed, HexImmediateStyle hex_style);
   bool CanBranch(llvm::MCInst &mc_inst) const;
   bool HasDelaySlot(llvm::MCInst &mc_inst) const;
@@ -607,7 +607,7 @@
 
 if (inst_size > 0) {
   mc_disasm_ptr->SetStyle(use_hex_immediates, hex_style);
-  mc_disasm_ptr->PrintMCInst(inst, out_string, comment_string);
+  mc_disasm_ptr->PrintMCInst(inst, pc, out_string, comment_string);
 
   if (!comment_string.empty()) {
 AppendComment(comment_string);
@@ -1290,6 +1290,8 @@
   if (!instr_printer_up)
 return Instance();
 
+  instr_printer_up->setPrintBranchImmAsAddress(true);
+
   // Not all targets may have registered createMCInstrAnalysis().
   std::unique_ptr instr_analysis_up(
   curr_target->createMCInstrAnalysis(instr_info_up.get()));
@@ -1337,13 +1339,13 @@
 }
 
 void DisassemblerLLVMC::MCDisasmInstance::PrintMCInst(
-llvm::MCInst &mc_inst, std::string &inst_string,
+llvm::MCInst &mc_inst, lldb::addr_t pc, std::string &inst_string,
 std::string &comments_string) {
   llvm::raw_string_ostream inst_stream(inst_string);
   llvm::raw_string_ostream comments_stream(comments_string);
 
   m_instr_printer_up->setCommentStream(comments_stream);
-  m_instr_printer_up->printInst(&mc_inst, 0, llvm::StringRef(),
+  m_instr_printer_up->printInst(&mc_inst, pc, llvm::StringRef(),
 *m_subtarget_info_up, inst_stream);
   m_instr_printer_up->setCommentStream(llvm::nulls());
   comments_stream.flush();


Index: lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
===
--- lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
+++ lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
@@ -60,8 +60,8 @@
 
   uint64_t GetMCInst(const uint8_t *opcode_data, size_t opcode_data_len,
  lldb::addr_t pc, llvm::MCInst &mc_inst) const;
-  void PrintMCInst(llvm::MCInst &mc_inst, std::string &inst_string,
-   std::string &comments_string);
+  void PrintMCInst(llvm::MCInst &mc_inst, lldb::addr_t pc,
+   std::string &inst_string, std::string &comments_string);
   void SetStyle(bool use_hex_immed, HexImmediateStyle hex_style);
   bool CanBranch(llvm::MCInst &mc_inst) const;
   bool HasDelaySlot(llvm::MCInst &mc_inst) const;
@@ -607,7 +607,7 @@
 
 if (inst_size > 0) {
   mc_disasm_ptr->SetStyle(use_hex_immediates, hex_style);
-  mc_disasm_ptr->PrintMCInst(inst, out_string, comment_string);
+  mc_disasm_ptr->PrintMCInst(inst, pc, out_string, comment_string);
 
   if (!comment_string.empty()) {
 AppendComment(comment_string);
@@ -1290,6 +1290,8 @@
   if (!instr_printer_up)
 return Instance();
 
+  instr_printer_up->setPrintBranchImmAsAddress(true);
+
   // Not all targets may have registered createMCInstrAnalysis().
   std::unique_ptr instr_analysis_up(
   curr_target->createMCInstrAnalysis(instr_info_up.get()));
@@ -1337,13 +1339,13 @@
 }
 
 void DisassemblerLLVMC::MCDisasmInstance::PrintMCInst(
-llvm::MCInst &mc_inst, std::string &inst_string,
+llvm::MCInst &mc_inst, lldb::addr_t pc, std::string &inst_string,
 std::string &comments_string) {
   llvm::raw_string_ostream inst_stream(inst_string);
   llvm::raw_string_ostream comments_stream(comments_string);
 
   m_instr_printer_up->setCommentStream(comments_stream);
-  m_instr_printer_up->printInst(&mc_inst, 0, llvm::StringRef(),
+  m_instr_printer_up->printInst(&mc_inst, pc, llvm::StringRef(),
 *m_subtarget_info_up, inst_stream);
   m_instr_printer_up->setCommentStream(llvm::nulls());
   comments_stream.flush();
___
lldb-commits mailing list

[Lldb-commits] [lldb] be88462 - Platform qemu-user: Build path to qemu automatically if not specified

[Ted Woodward via lldb-commits]

Author: Ted Woodward
Date: 2023-08-22T14:20:18-05:00
New Revision: be88462cd6aa819c22185ff0916988d4f03b6ab0

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

LOG: Platform qemu-user: Build path to qemu automatically if not specified

Get the path to qemu in the following order:
1) From the property platform.plugin.qemu-user.emulator-path
2) If that property is not set, from PATH, building the name of the qemu
   binary from the triple in  property platform.plugin.qemu-user.architecture
3) If that property is not set, from PATH, building the name of the qemu
   binary from the triple in the target

This will allow a user to load a target and run without setting properties,
if qemu is on the PATH and named qemu-

Reviewed By: labath

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

Added: 


Modified: 
lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp 
b/lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
index 72a039d18872758..b233b1ba9b5899c 100644
--- a/lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
+++ b/lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
@@ -162,9 +162,18 @@ lldb::ProcessSP 
PlatformQemuUser::DebugProcess(ProcessLaunchInfo &launch_info,
Target &target, Status &error) {
   Log *log = GetLog(LLDBLog::Platform);
 
+  // If platform.plugin.qemu-user.emulator-path is set, use it.
   FileSpec qemu = GetGlobalProperties().GetEmulatorPath();
-  if (!qemu)
-qemu.SetPath(("qemu-" + GetGlobalProperties().GetArchitecture()).str());
+  // If platform.plugin.qemu-user.emulator-path is not set, build the
+  // executable name from platform.plugin.qemu-user.architecture.
+  if (!qemu) {
+llvm::StringRef arch = GetGlobalProperties().GetArchitecture();
+// If platform.plugin.qemu-user.architecture is not set, build the
+// executable name from the target Triple's ArchName
+if (arch.empty())
+  arch = target.GetArchitecture().GetTriple().getArchName();
+qemu.SetPath(("qemu-" + arch).str());
+  }
   FileSystem::Instance().ResolveExecutableLocation(qemu);
 
   llvm::SmallString<0> socket_model, socket_path;



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

[Lldb-commits] [PATCH] D155117: Platform qemu-user: Build path to qemu automatically if not specified

[Ted Woodward via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe88462cd6aa: Platform qemu-user: Build path to qemu 
automatically if not specified (authored by ted).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155117

Files:
  lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp


Index: lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
===
--- lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
+++ lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
@@ -162,9 +162,18 @@
Target &target, Status &error) {
   Log *log = GetLog(LLDBLog::Platform);
 
+  // If platform.plugin.qemu-user.emulator-path is set, use it.
   FileSpec qemu = GetGlobalProperties().GetEmulatorPath();
-  if (!qemu)
-qemu.SetPath(("qemu-" + GetGlobalProperties().GetArchitecture()).str());
+  // If platform.plugin.qemu-user.emulator-path is not set, build the
+  // executable name from platform.plugin.qemu-user.architecture.
+  if (!qemu) {
+llvm::StringRef arch = GetGlobalProperties().GetArchitecture();
+// If platform.plugin.qemu-user.architecture is not set, build the
+// executable name from the target Triple's ArchName
+if (arch.empty())
+  arch = target.GetArchitecture().GetTriple().getArchName();
+qemu.SetPath(("qemu-" + arch).str());
+  }
   FileSystem::Instance().ResolveExecutableLocation(qemu);
 
   llvm::SmallString<0> socket_model, socket_path;


Index: lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
===
--- lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
+++ lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
@@ -162,9 +162,18 @@
Target &target, Status &error) {
   Log *log = GetLog(LLDBLog::Platform);
 
+  // If platform.plugin.qemu-user.emulator-path is set, use it.
   FileSpec qemu = GetGlobalProperties().GetEmulatorPath();
-  if (!qemu)
-qemu.SetPath(("qemu-" + GetGlobalProperties().GetArchitecture()).str());
+  // If platform.plugin.qemu-user.emulator-path is not set, build the
+  // executable name from platform.plugin.qemu-user.architecture.
+  if (!qemu) {
+llvm::StringRef arch = GetGlobalProperties().GetArchitecture();
+// If platform.plugin.qemu-user.architecture is not set, build the
+// executable name from the target Triple's ArchName
+if (arch.empty())
+  arch = target.GetArchitecture().GetTriple().getArchName();
+qemu.SetPath(("qemu-" + arch).str());
+  }
   FileSystem::Instance().ResolveExecutableLocation(qemu);
 
   llvm::SmallString<0> socket_model, socket_path;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 9e66ea5 - Revert "[LLDB] Allow expression evaluators to set arbitrary timeouts"

[walter erquinigo via lldb-commits]

Author: walter erquinigo
Date: 2023-08-22T17:04:53-04:00
New Revision: 9e66ea503ea1727b333ecb088e73e81a4c0736d5

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

LOG: Revert "[LLDB] Allow expression evaluators to set arbitrary timeouts"

This reverts commit a4dbdf4749938396dbf913478289fa426d8341ae because it breaks 
the buildbot https://lab.llvm.org/buildbot/#/builders/68/builds/58591

Added: 


Modified: 
lldb/include/lldb/Target/Target.h

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index ed0ecbbddbf814..f86bd3cb4ee55d 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -346,9 +346,16 @@ class EvaluateExpressionOptions {
 m_use_dynamic = dynamic;
   }
 
-  const Timeout &GetTimeout() const { return m_timeout; }
+  const Timeout &GetTimeout() const {
+assert(m_timeout && m_timeout->count() > 0);
+return m_timeout;
+  }
 
-  void SetTimeout(const Timeout &timeout) { m_timeout = timeout; }
+  void SetTimeout(const Timeout &timeout) {
+// Disallow setting a non-zero timeout.
+if (timeout && timeout->count() > 0)
+  m_timeout = timeout;
+  }
 
   const Timeout &GetOneThreadTimeout() const {
 return m_one_thread_timeout;



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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

@wallace  this is breaking TestIRInterpreter.py on macOS now;  
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ has been failing 
since it went in (there was another llvm issue causing failures right before 
this went in, so it was easy to miss).  On my desktop this change results in 
TestIRInterpreter.py running without end; I think the bots kill tests that run 
for more than 5 minutes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[walter erquinigo via Phabricator via lldb-commits]

wallace added a comment.

@jasonmolenda , yep. I have already reverted this patch. I'll figure out how to 
make that work nicely with these changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D157764#4608265 , @wallace wrote:

> @jasonmolenda , yep. I have already reverted this patch. I'll figure out how 
> to make that work nicely with these changes.

oh lol sorry took me a little while to confirm and I missed that.  :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D157764#4608265 , @wallace wrote:

> @jasonmolenda , yep. I have already reverted this patch. I'll figure out how 
> to make that work nicely with these changes.

My recommendation would be to change the timeout in the test from 0 to 500ms to 
maintain the previous behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

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

[Lldb-commits] [lldb] 7822e5d - [LLDB] Allow expression evaluators to set arbitrary timeouts

[walter erquinigo via lldb-commits]

Author: walter erquinigo
Date: 2023-08-22T17:41:14-04:00
New Revision: 7822e5dbf1cb4be2d73eb13da27b04de684c318b

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

LOG: [LLDB] Allow expression evaluators to set arbitrary timeouts

https://github.com/llvm/llvm-project/commit/59237bb52c9483fce395428bfab5996eabe54ed0
 changed the behavior of the `SetTimeout` and `GetTimeout` methods of 
`EvaluateExpressionOptions`, which broke the Mojo REPL and related services 
(https://docs.modular.com/mojo/) because it relies on having infinite timeouts. 
That's a necessity because developers often use the REPL for executing 
extremely long-running numeric jobs. Having said that, 
`EvaluateExpressionOptions` shouldn't be that opinionated on this matter 
anyway. Instead, it should be the responsibility of the evaluator to define 
which timeout to use for each specific case.

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

Added: 


Modified: 
lldb/include/lldb/Target/Target.h
lldb/test/API/commands/expression/ir-interpreter/TestIRInterpreter.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index f86bd3cb4ee55d..ed0ecbbddbf814 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -346,16 +346,9 @@ class EvaluateExpressionOptions {
 m_use_dynamic = dynamic;
   }
 
-  const Timeout &GetTimeout() const {
-assert(m_timeout && m_timeout->count() > 0);
-return m_timeout;
-  }
+  const Timeout &GetTimeout() const { return m_timeout; }
 
-  void SetTimeout(const Timeout &timeout) {
-// Disallow setting a non-zero timeout.
-if (timeout && timeout->count() > 0)
-  m_timeout = timeout;
-  }
+  void SetTimeout(const Timeout &timeout) { m_timeout = timeout; }
 
   const Timeout &GetOneThreadTimeout() const {
 return m_one_thread_timeout;

diff  --git 
a/lldb/test/API/commands/expression/ir-interpreter/TestIRInterpreter.py 
b/lldb/test/API/commands/expression/ir-interpreter/TestIRInterpreter.py
index 5f98bb51a49c1b..0515876734ca49 100644
--- a/lldb/test/API/commands/expression/ir-interpreter/TestIRInterpreter.py
+++ b/lldb/test/API/commands/expression/ir-interpreter/TestIRInterpreter.py
@@ -31,8 +31,8 @@ def test_interpreter_timeout(self):
 # This is an IRInterpreter specific test, so disable the JIT.
 options.SetAllowJIT(False)
 
-# No timeout means a 500ms.
-options.SetTimeoutInMicroSeconds(0)
+# We use a 500ms timeout.
+options.SetTimeoutInMicroSeconds(50)
 res, duration_sec = self.time_expression(inf_loop, options)
 self.assertIn(timeout_error, str(res.GetError()))
 



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

[Lldb-commits] [PATCH] D157764: [LLDB] Allow expression evaluators to set arbitrary timeouts

[walter erquinigo via Phabricator via lldb-commits]

wallace added a comment.

@JDevlieghere , that worked. Thanks!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157764

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

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

LGTM, fwiw.




Comment at: lldb/docs/use/aarch64-linux.rst:37
+The example above has a vector length of 16 bytes. Within LLDB you will always
+see "vg" as in the ``vg`` register, which is 2 in this case (8*2 = 16).
+Elsewhere you may see "vq" which is the vector length in quadwords (16 bytes)

You describe vg without noting the size, but note the size of vq and vl.  Maybe 
these could be described similarly, as counting doublewords/quadwords/bytes.



Comment at: lldb/docs/use/aarch64-linux.rst:39
+Elsewhere you may see "vq" which is the vector length in quadwords (16 bytes)
+elsewhere. Where you see "vl", it is in bytes.
+

drop second elsewhere



Comment at: lldb/docs/use/aarch64-linux.rst:115
+* ``svcr`` the Streaming Vector Control Register. This is actually a pseduo
+  register but it matches the content of the architecturaly defined ``SVCR``.
+  This is the register you should use to check whether streaming mode and/or

architecturally


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158506

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

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Greg Clayton via Phabricator via lldb-commits]

clayborg created this revision.
clayborg added reviewers: labath, JDevlieghere, GeorgeHuyubo, yinghuitan, 
kusmour.
Herald added a project: All.
clayborg requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

We ran into a case where shared libraries would fail to load in some processes 
on linux. The issue turned out to be if the main executable or a shared library 
defined a symbol named "_r_debug", then it would cause problems once the 
executable that contained it was loaded into the process. The "_r_debug" 
structure is currently found by looking through the .dynamic section in the 
main executable and finding the DT_DEBUG entry which points to this structure. 
The dynamic loader will update this structure as shared libraries are loaded 
and LLDB watches the contents of this structure as the dyld breakpoint is hit. 
Currently we expect the "state" in this structure to change as things happen. 
An issue comes up if someone defines another "_r_debug" struct in their program:

  r_debug _r_debug;

If this code is included, a new "_r_debug" structure is created and it causes 
problems once the executable is loaded. This is because of the way symbol 
lookups happen in linux: they use the shared library list in the order it 
created and the dynamic loader is always last. So at some point the dynamic 
loader will start updating this other copy of "_r_debug", yet LLDB is only 
watching the copy inside of the dynamic loader.

Steps that show the problem are:

- lldb finds the "_r_debug" structure via the DT_DEBUG entry in the .dynamic 
section and this points to the "_r_debug" in ld.so
- ld.so modifies its copy of "_r_debug" with "state = eAdd" before it loads the 
shared libraries and calls the dyld function that LLDB has set a breakpoint on 
and we find this state and do nothing (we are waiting for a state of 
eConsistent to tell us the shared libraries have been fully loaded)
- ld.so loads the main executable and any dependent shared libraries and wants 
to update the "_r_debug" structure, but it now finds "_r_debug" in the a.out 
program and updates the state in this other copy
- lldb hits the notification breakpoint and checks the ld.so copy of "_r_debug" 
which still has a state of "eAdd". LLDB wants the new "eConsistent" state which 
will trigger the shared libraries to load, but it gets stale data and doesn't 
do anyhing and library load is missed. The "_r_debug" in a.out has the state 
set correctly, but we don't know which "_r_debug" is the right one.

The new fix detects the two "eAdd" states and loads shared libraries and will 
emit a log message in the "log enable lldb dyld" log channel which states there 
might be multiple "_r_debug" structs.

The correct solution is that no one should be adding a duplicate "_r_debug" 
symbol to their binaries, but we have programs that are doing this already and 
since it can be done, we should be able to work with this and keep debug 
sessions working as expected. If a user #includes the  file, they can 
just use the existing "_r_debug" structure as it is defined in this header file 
as "extern struct r_debug _r_debug;" and no local copies need to be made.

If your ld.so has debug info, you can easily see the duplicate "_r_debug" 
structs by doing:

  (lldb) target variable _r_debug --raw
  (r_debug) _r_debug = {
r_version = 1
r_map = 0x77e30210
r_brk = 140737349972416
r_state = RT_CONSISTENT
r_ldbase = 0
  }
  (r_debug) _r_debug = {
r_version = 1
r_map = 0x77e30210
r_brk = 140737349972416
r_state = RT_ADD
r_ldbase = 140737349943296
  }
  (lldb) target variable &_r_debug
  (r_debug *) &_r_debug = 0x55601040
  (r_debug *) &_r_debug = 0x77e301e0

And if you do a "image lookup --address " in the addresses, you can see 
one is in the a.out and one in the ld.so.

Adding more logging to print out the m_previous and m_current Rendezvous 
structures to make things more clear. Also added a log when we detect multiple 
eAdd states in a row to detect this problem in logs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158583

Files:
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/Makefile
  
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.cpp
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp

Index: lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
@@ -0,0 +1,32 @@
+#include "library_file.h"
+#include 
+#include 
+// Make a duplicate "_r_debug" symbol that is visible. T