[Lldb-commits] [lldb] [lldb] Include SBLanguages in the SWIG bindings (PR #92470)
https://github.com/bulbazord approved this pull request. Ok, that should work. CMake knows about SBLanguages.h since there are rules to generate it. https://github.com/llvm/llvm-project/pull/92470 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Include SBLanguages in the SWIG bindings (PR #92470)
https://github.com/bulbazord requested changes to this pull request. Actually, this has no dependency tracking. You'll need to add that for this to work every time. https://github.com/llvm/llvm-project/pull/92470 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Include SBLanguages in the SWIG bindings (PR #92470)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/92470 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+ SBAddressRangeList();
+
+ SBAddressRangeList(const lldb::SBAddressRangeList );
+
+ ~SBAddressRangeList();
+
+ const lldb::SBAddressRangeList &
+ operator=(const lldb::SBAddressRangeList );
+
+ uint32_t GetSize() const;
+
+ void Clear();
+
+ bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRangeList _range_list);
+
+protected:
+ const AddressRangeListImpl *operator->() const;
+
+ const AddressRangeListImpl *() const;
+
+private:
+ friend class SBProcess;
+
+ lldb_private::AddressRanges ();
+
+ const lldb_private::AddressRanges () const;
bulbazord wrote:
To be clear, I'm objecting to these methods existing at all. I re-read the code
and my comment and realized my argument didn't actually make a ton of sense, so
allow me to clarify:
I don't think we should be exposing `ref` at all here. I can understand having
private methods to access the underlying `AddressRangeListImpl` (so that other
classes can access it and mess with it, we do this all the time). What I don't
think is a good idea is having a method to access implementation details of
`AddressRangeListImpl` (namely, `AddressRanges`).
Instead, I'm suggesting that we shuffle some code around to avoid exposing
these at all. The problem that these solve is that other classes may want to
privately modify the underlying `AddressRangeListImpl`, but don't have access
to the class. All they have is a forward declaration (because they include this
header and the implementation is in the cpp file). My suggestion would be to
create a private header `AddressRangeListImpl.h` in `source/API`. Then any
class that wants to modify the underlying `AddressRangeListImpl` can do so
without needing to know that `AddressRangeListImpl` is implemented with
`AddressRanges`.
Normally I try not to push back against things here, but you cannot change or
remove things from the SBAPI ever. Not even private methods like these (as I
found out when I broke the ABI on Windows last year).
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -242,6 +244,12 @@ class AddressRange {
lldb::addr_t m_byte_size = 0; ///< The size in bytes of this address range.
};
+// Forward-declarable wrapper.
+class AddressRanges : public std::vector {
+public:
+ using std::vector::vector;
+};
bulbazord wrote:
Sorry, "above" was the wrong word. I meant "below", but to be even more
specific, I'm referring to this:
https://github.com/llvm/llvm-project/pull/92014#discussion_r1602020217
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -242,6 +244,12 @@ class AddressRange {
lldb::addr_t m_byte_size = 0; ///< The size in bytes of this address range.
};
+// Forward-declarable wrapper.
+class AddressRanges : public std::vector {
+public:
+ using std::vector::vector;
+};
bulbazord wrote:
I see, you're following the convention for `SBMemoryRegionInfoList`. In the
discussion above with Greg I proposed a different solution.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+ SBAddressRangeList();
+
+ SBAddressRangeList(const lldb::SBAddressRangeList );
+
+ ~SBAddressRangeList();
+
+ const lldb::SBAddressRangeList &
+ operator=(const lldb::SBAddressRangeList );
+
+ uint32_t GetSize() const;
+
+ void Clear();
+
+ bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRangeList _range_list);
+
+protected:
+ const AddressRangeListImpl *operator->() const;
+
+ const AddressRangeListImpl *() const;
+
+private:
+ friend class SBProcess;
+
+ lldb_private::AddressRanges ();
+
+ const lldb_private::AddressRanges () const;
bulbazord wrote:
Even if other APIs need a reference to the combined address ranges, we could
have a private header for `AddressRangeListImpl` in `source/API` so other
classes can access it. I don't think we need to expose
`lldb_private::AddressRanges` here. I don't want to expose the `AddressRanges`
class in the ABI (through mangled names).
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)
https://github.com/bulbazord requested changes to this pull request. Hmm, actually, I'm not so sure about this change anymore. I went through PEP8 again and saw this: ``` Don’t compare boolean values to True or False using ==: # Correct: if greeting: # Wrong: if greeting == True: Worse: # Wrong: if greeting is True: ``` This doesn't seem like the right change then, no? https://github.com/llvm/llvm-project/pull/91858 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+ SBAddressRange();
+
+ SBAddressRange(const lldb::SBAddressRange );
+
+ SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+ ~SBAddressRange();
+
+ const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+ void Clear();
+
+ bool IsValid() const;
+
+ /// Get the base address of the range.
+ ///
+ /// \return
+ /// Base address object.
+ lldb::SBAddress GetBaseAddress() const;
+
+ /// Get the byte size of this range.
+ ///
+ /// \return
+ /// The size in bytes of this address range.
+ lldb::addr_t GetByteSize() const;
+
+protected:
+ friend class SBAddressRangeList;
+ friend class SBBlock;
+ friend class SBFunction;
+
+ lldb_private::AddressRange ();
+
+ const lldb_private::AddressRange () const;
+
+private:
+ AddressRangeUP m_opaque_up;
+};
+
+#ifndef SWIG
+bool LLDB_API operator==(const SBAddressRange , const SBAddressRange );
+#endif
bulbazord wrote:
Yes, I would strongly prefer that. Freestanding operators are powerful and
useful, but in my experience they cause headaches when trying to use them with
tooling. (e.g. swift/C++ interop, clang-based tooling, etc.)
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
bulbazord wrote: I forgot to ask, what is the motivation behind this change? Is there something you can't do with the SBAPI right now or that is better expressed with SBAddressRange and SBAddressRangeList? https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,130 @@ + bulbazord wrote: remove stray line https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,130 @@
+
+//===-- SBAddressRangeList.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRangeList.h"
+#include "Utils.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class AddressRangeListImpl {
+public:
+ AddressRangeListImpl() : m_ranges() {}
+
+ AddressRangeListImpl(const AddressRangeListImpl ) = default;
+
+ AddressRangeListImpl =(const AddressRangeListImpl ) {
+if (this == )
+ return *this;
+m_ranges = rhs.m_ranges;
+return *this;
+ }
+
+ size_t GetSize() const { return m_ranges.size(); }
+
+ void Reserve(size_t capacity) { return m_ranges.reserve(capacity); }
bulbazord wrote:
no need for return on this line, returns void.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+ SBAddressRange();
+
+ SBAddressRange(const lldb::SBAddressRange );
+
+ SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
bulbazord wrote:
`file_addr` seems like it may be a bit misleading. It might not be an address
in a file. Maybe `base_addr`?
Why is `byte_size` an `addr_t` instead of, say, a `size_t` or `uint64_t`?
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,124 @@
+"""
+Test SBAddressRange APIs.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+
+
+class AddressRangeTestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_address_range_default(self):
+"""Testing default constructor."""
+empty_range = lldb.SBAddressRange()
+self.assertEqual(empty_range.IsValid(), False)
+
+def test_address_range_construction(self):
+"""Make sure the construction and getters work."""
+range = lldb.SBAddressRange(0x0400, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress().GetOffset(), 0x0400)
+self.assertEqual(range.GetByteSize(), 8)
+
+def test_address_range_clear(self):
+"""Make sure the clear method works."""
+range = lldb.SBAddressRange(0x0400, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress().GetOffset(), 0x0400)
+self.assertEqual(range.GetByteSize(), 8)
+
+range.Clear()
+self.assertEqual(range.IsValid(), False)
+
+def test_function(self):
+"""Make sure the range works in SBFunction APIs."""
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+# Setup breakpoints in main
+bp = target.BreakpointCreateByName("main", "a.out")
+loc = bp.GetLocationAtIndex(0)
+loc_addr = loc.GetAddress()
+func = loc_addr.GetFunction()
+# block = loc_addr.GetBlock()
+range = func.GetRange()
+# block_ranges = block.GetRangeAtIndex(0)
bulbazord wrote:
Please remove the commented out lines in the test (or uncomment them and use
them)
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+ SBAddressRangeList();
+
+ SBAddressRangeList(const lldb::SBAddressRangeList );
+
+ ~SBAddressRangeList();
+
+ const lldb::SBAddressRangeList &
+ operator=(const lldb::SBAddressRangeList );
+
+ uint32_t GetSize() const;
+
+ void Clear();
+
+ bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRange _range);
+
+ void Append(const lldb::SBAddressRangeList _range_list);
+
+protected:
bulbazord wrote:
In the public API, we can't really do inheritance. These methods should be
private.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
https://github.com/bulbazord requested changes to this pull request. https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -242,6 +244,12 @@ class AddressRange {
lldb::addr_t m_byte_size = 0; ///< The size in bytes of this address range.
};
+// Forward-declarable wrapper.
+class AddressRanges : public std::vector {
+public:
+ using std::vector::vector;
+};
bulbazord wrote:
Why do you wrap this instead of using `std::vector`
below?
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include
+#include
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+ LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+ LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+ return *this;
+}
+
+void SBAddressRange::Clear() {
+ LLDB_INSTRUMENT_VA(this);
+
+ m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+ return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+ LLDB_INSTRUMENT_VA(this);
+
+ assert(m_opaque_up.get() && "AddressRange is NULL");
bulbazord wrote:
We definitely do not want to assert here. Taking down the entire process
because somebody has an invalid address range and tried to ask for data is
definitely not a safe solution. In this case, it should return an empty
SBAddress.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -160,6 +160,17 @@ SBAddress SBFunction::GetEndAddress() {
return addr;
}
+lldb::SBAddressRange SBFunction::GetRange() {
+ LLDB_INSTRUMENT_VA(this);
+
+ lldb::SBAddressRange range;
+ if (m_opaque_ptr) {
+range.ref() = m_opaque_ptr->GetAddressRange();
+ }
bulbazord wrote:
Remove braces around single line blocks (per LLVM guidelines)
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGELIST_H
+#define LLDB_API_SBADDRESSRANGELIST_H
+
+#include
+
+#include "lldb/API/SBDefines.h"
+
+class AddressRangeListImpl;
+
+namespace lldb {
+
+class LLDB_API SBAddressRangeList {
+public:
+ SBAddressRangeList();
+
+ SBAddressRangeList(const lldb::SBAddressRangeList );
+
+ ~SBAddressRangeList();
+
+ const lldb::SBAddressRangeList &
+ operator=(const lldb::SBAddressRangeList );
+
+ uint32_t GetSize() const;
+
+ void Clear();
+
+ bool GetAddressRangeAtIndex(uint64_t idx, SBAddressRange _range);
bulbazord wrote:
Why doesn't this just return `SBAddressRange`? There are then 2 ways to check
the validity of the range (the return value and what's in `addr_range`).
Also, why is the index `uint64_t` but the return value of GetSize is
`uint32_t`? Seems like both are related to the possible indices of the list, we
should pick one and use it everywhere.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Utility/Instrumentation.h"
+#include
+#include
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+ LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(file_addr, byte_size)) {
+ LLDB_INSTRUMENT_VA(this, file_addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange ::operator=(const SBAddressRange ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ if (this != )
+m_opaque_up = clone(rhs.m_opaque_up);
+ return *this;
+}
+
+void SBAddressRange::Clear() {
+ LLDB_INSTRUMENT_VA(this);
+
+ m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+ return m_opaque_up && m_opaque_up->IsValid();
bulbazord wrote:
Missing instrumentation macro
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_SBADDRESSRANGE_H
+#define LLDB_API_SBADDRESSRANGE_H
+
+#include "lldb/API/SBDefines.h"
+
+namespace lldb {
+
+class LLDB_API SBAddressRange {
+public:
+ SBAddressRange();
+
+ SBAddressRange(const lldb::SBAddressRange );
+
+ SBAddressRange(lldb::addr_t file_addr, lldb::addr_t byte_size);
+
+ ~SBAddressRange();
+
+ const lldb::SBAddressRange =(const lldb::SBAddressRange );
+
+ void Clear();
+
+ bool IsValid() const;
+
+ /// Get the base address of the range.
+ ///
+ /// \return
+ /// Base address object.
+ lldb::SBAddress GetBaseAddress() const;
+
+ /// Get the byte size of this range.
+ ///
+ /// \return
+ /// The size in bytes of this address range.
+ lldb::addr_t GetByteSize() const;
+
+protected:
+ friend class SBAddressRangeList;
+ friend class SBBlock;
+ friend class SBFunction;
+
+ lldb_private::AddressRange ();
+
+ const lldb_private::AddressRange () const;
+
+private:
+ AddressRangeUP m_opaque_up;
+};
+
+#ifndef SWIG
+bool LLDB_API operator==(const SBAddressRange , const SBAddressRange );
+#endif
bulbazord wrote:
Please don't introduce new freestanding operators. This was a mistake when we
did it in SBAddress and can't really remove it anymore, let's try to limit this.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/92014 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add CMake dependency tracking for SBLanguages generation script (PR #91686)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/91686 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB/Coredump] Only take the Pthread from start start to the stackpointer + red_zone (PR #92002)
@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process , if (!reg_ctx_sp) continue; const addr_t sp = reg_ctx_sp->GetSP(); +const size_t red_zone = process.GetABI()->GetRedZoneSize(); bulbazord wrote: Asking for my understanding: This will only really do anything if the size of the red zone is greater than 0 right? Otherwise, this change is a no-op. Is that right? https://github.com/llvm/llvm-project/pull/92002 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem instances to expression log (PR #91985)
https://github.com/bulbazord approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/91985 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ExpressionParser][NFCI] Log pointers as hex (PR #91989)
https://github.com/bulbazord approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/91989 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)
https://github.com/bulbazord approved this pull request. LGTM The PR summary is empty, but it looks like the commit message has an explanation for this change, so that's fine. https://github.com/llvm/llvm-project/pull/91858 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Put SBSourceLanguageName in lldb namespace (PR #91685)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/91685 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add CMake dependency tracking for SBLanguages generation script (PR #91686)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/91686
If you change the generation script and re-run ninja (or whatever drives your
build), it currently will not regenerate SBLanguages.h. With dependency
tracking, it should re-run when the script changes.
>From ba9f8753702fee417f2d00321a40d80dfb025795 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Thu, 9 May 2024 17:37:08 -0700
Subject: [PATCH] [lldb] Add CMake dependency tracking for SBLanguages
generation script
If you change the generation script and re-run ninja (or whatever
drives your build), it currently will not regenerate SBLanguages.h.
With dependency tracking, it should re-run when the script changes.
---
lldb/source/API/CMakeLists.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index aa31caddfde3a..76b42ecf63f91 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -23,14 +23,17 @@ endif()
# Generate SBLanguages.h from Dwarf.def.
set(sb_languages_file
${CMAKE_CURRENT_BINARY_DIR}/../../include/lldb/API/SBLanguages.h)
+set(sb_languages_generator
+ ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py)
add_custom_command(
COMMENT "Generating SBLanguages.h from Dwarf.def"
COMMAND "${Python3_EXECUTABLE}"
- ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py
+ ${sb_languages_generator}
${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
-o ${sb_languages_file}
OUTPUT ${sb_languages_file}
DEPENDS ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
+ ${sb_languages_generator}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
)
add_custom_target(lldb-sbapi-dwarf-enums
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Put SBSourceLanguageName in lldb namespace (PR #91685)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/91685
None
>From 6c2ea1ff493a55fc4713c4bc58ef6e659e1c7b9d Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Thu, 9 May 2024 17:27:42 -0700
Subject: [PATCH] [lldb] Put SBSourceLanguageName in lldb namespace
---
lldb/scripts/generate-sbapi-dwarf-enum.py | 4
1 file changed, 4 insertions(+)
diff --git a/lldb/scripts/generate-sbapi-dwarf-enum.py
b/lldb/scripts/generate-sbapi-dwarf-enum.py
index f7a13e5efffef..7fd6037986317 100755
--- a/lldb/scripts/generate-sbapi-dwarf-enum.py
+++ b/lldb/scripts/generate-sbapi-dwarf-enum.py
@@ -15,6 +15,8 @@
#ifndef LLDB_API_SBLANGUAGE_H
#define LLDB_API_SBLANGUAGE_H
+
+namespace lldb {
/// Used by \\ref SBExpressionOptions.
/// These enumerations use the same language enumerations as the DWARF
/// specification for ease of use and consistency.
@@ -24,6 +26,8 @@
FOOTER = """\
};
+} // namespace lldb
+
#endif
"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91653 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
bulbazord wrote:
This must necessarily be a file right? It's in the `files` output of `os.walk`.
Could it be something else?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
bulbazord wrote:
Do we expect `abs_path` to not exist after the call to `find`?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Enforce image loading policy (PR #91109)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
+
+ void SetNiceValue(int8_t nice_value) { m_nice_value = nice_value; }
+
+ bool NiceValueIsValid() const;
+
+ void SetIsZombie() { m_zombie = true; }
bulbazord wrote:
Is there a way to unset it being a zombie?
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
bulbazord wrote:
Suggestion: `nice` -> `priority_level` or something similar. The unix world
uses the words `nice` and `niceness` but Windows and other platforms do not.
It's also not a very obvious word if you lack the domain expertise.
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Enforce image loading policy (PR #91109)
@@ -526,6 +526,47 @@ def create_target(self): def get_target(self): return self.target +def load_images(self, options, loaded_images=[]): bulbazord wrote: Suggestion: Default `loaded_images` to `None`. You probably don't want `loaded_images` to default to `[]`. It will persist between calls, e.g.: ``` >>> def foo(x, lst=[]): ... lst.append(x) ... print(lst) ... >>> foo(1) [1] >>> foo(2) [1, 2] ``` https://github.com/llvm/llvm-project/pull/91109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
bulbazord wrote:
The assertions in this code are going to blow up only in development builds. In
release builds, you'll fall through the first assertion, and return because you
try to cast `nullptr` to a NamedDecl (which will give you `nullptr`) and the
function will fail silently. The second assertion will fail if `from_ast` or
`to_ast` is `nullptr`, but the function doesn't return early there. It will
call `getDisplayName` on `from_ast` and `to_ast`, one of which will crash
anyway. Maybe we should consider an early return here too? Or maybe the
function should return an `llvm::Error`?
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Sort ranges list in dwarf 5. (PR #91343)
https://github.com/bulbazord approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/91343 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
@@ -400,6 +400,12 @@ friend class Breakpoint;
/// Which options are set at this level.
/// Drawn from BreakpointOptions::SetOptionsFlags.
Flags m_set_flags;
+ /// Settings that allow the 'disabled' keyword to be displayed in red.
+ Stream::HighlightSettings m_disbaled_breakpoint_highlight_settings{
+ "disabled",
+ "\x1b[31m",
+ "\x1b[37m",
bulbazord wrote:
You don't need to hardcode these values yourself. Take a look at
`AnsiTerminal.h`, there are some constants defined for this purpose.
https://github.com/llvm/llvm-project/pull/91404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
@@ -400,6 +400,12 @@ friend class Breakpoint;
/// Which options are set at this level.
/// Drawn from BreakpointOptions::SetOptionsFlags.
Flags m_set_flags;
+ /// Settings that allow the 'disabled' keyword to be displayed in red.
+ Stream::HighlightSettings m_disbaled_breakpoint_highlight_settings{
bulbazord wrote:
typo: `disbaled` -> `disabled`
https://github.com/llvm/llvm-project/pull/91404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
https://github.com/bulbazord requested changes to this pull request. https://github.com/llvm/llvm-project/pull/91404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/91404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Reinstate lldb-sbapi-dwarf-enums target (NFC) (PR #91390)
https://github.com/bulbazord approved this pull request. Thanks for taking care of that. https://github.com/llvm/llvm-project/pull/91390 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Sort ranges list in dwarf 5. (PR #91343)
bulbazord wrote: > For example: > https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927. > When parsing function info, it validates low and hi address of the function: > `GetMinRangeBase` returns the first range entry base and `GetMaxRangeEnd` > returns the last range end. If low >= hi, it stops parsing this function. > > This causes missing inline stack frames for us when debugging a core dump. Gotcha, makes sense. Since you know how this fails, could you add a test to make sure that scenario continues working? https://github.com/llvm/llvm-project/pull/91343 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)
@@ -731,8 +747,11 @@ class Debugger : public std::enable_shared_from_this, lldb::TargetSP m_dummy_target_sp; Diagnostics::CallbackID m_diagnostics_callback_id; - lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr; - void *m_destroy_callback_baton = nullptr; + std::recursive_mutex m_destroy_callback_mutex; bulbazord wrote: @JDevlieghere Yes, I don't think we need to synchronize across threads, that's a good point. I was thinking about what if any of the callbacks add, remove, or otherwise invoke other callbacks. But that shouldn't require a mutex. @royitaqi I think you can remove the mutex :) https://github.com/llvm/llvm-project/pull/89868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][DWARF] Sort ranges list in dwarf 5. (PR #91343)
bulbazord wrote: > Some places assume the ranges are already sorted but it's not. This fixes it. What places assumed it was sorted? I assume this means there are some bugs that this fixes? Can you give some more details about how you came to write this patch? https://github.com/llvm/llvm-project/pull/91343 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use add_custom_command for SBLanguages.h (PR #91254)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91254 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use add_custom_command for SBLanguages.h (PR #91254)
bulbazord wrote: This should work if there is exactly one thing that depends on the output of this custom command. If multiple things start depending on the generated files, you may end up with weird results. See: https://cmake.org/cmake/help/latest/command/add_custom_command.html > Do not list the output in more than one independent target that may build in > parallel or the instances of the rule may conflict. Instead, use the > [add_custom_target()](https://cmake.org/cmake/help/latest/command/add_custom_target.html#command:add_custom_target) > command to drive the command and make the other targets depend on that one. > See the [Example: Generating Files for Multiple > Targets](https://cmake.org/cmake/help/latest/command/add_custom_command.html#example-generating-files-for-multiple-targets) > below. https://github.com/llvm/llvm-project/pull/91254 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -85,3 +86,84 @@ def test_command_output(self):
self.assertEqual(res.GetOutput(), "")
self.assertIsNotNone(res.GetError())
self.assertEqual(res.GetError(), "")
+
+def test_structured_transcript(self):
+"""Test structured transcript generation and retrieval."""
+# Get command interpreter and create a target
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+ci = self.dbg.GetCommandInterpreter()
+self.assertTrue(ci, VALID_COMMAND_INTERPRETER)
+
+# Send a few commands through the command interpreter
+res = lldb.SBCommandReturnObject()
+ci.HandleCommand("version", res)
+ci.HandleCommand("an-unknown-command", res)
+ci.HandleCommand("breakpoint set -f main.c -l %d" % self.line, res)
+ci.HandleCommand("r", res)
+ci.HandleCommand("p a", res)
+total_number_of_commands = 5
+
+# Retrieve the transcript and convert it into a Python object
+transcript = ci.GetTranscript()
+self.assertTrue(transcript.IsValid())
+
+stream = lldb.SBStream()
+self.assertTrue(stream)
+
+error = transcript.GetAsJSON(stream)
+self.assertSuccess(error)
+
+transcript = json.loads(stream.GetData())
+
+# The transcript will contain a bunch of commands that are run
+# automatically. We only want to validate for the ones that are
+# listed above, hence trimming to the last parts.
+transcript = transcript[-total_number_of_commands:]
bulbazord wrote:
I think that's fine. Thanks for checking.
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFCI] Remove unused DWARF value-to-name functions (PR #91010)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/91010 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFCI] Remove unused DWARF value-to-name functions (PR #91010)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/91010
I was cleaning up this portion of the code and realized these are completely
unused.
>From be459e6a4e611650094ed9d362bf84acb9aabe16 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Fri, 3 May 2024 13:35:19 -0700
Subject: [PATCH] [lldb][NFCI] Remove unused DWARF value-to-name functions
I was cleaning up this portion of the code and realized these are
completely unused.
---
.../Plugins/SymbolFile/DWARF/DWARFDefines.cpp | 50 ---
.../Plugins/SymbolFile/DWARF/DWARFDefines.h | 12 -
2 files changed, 62 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp
index 1f0e10ef27018b..2fb0c224bf8e84 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp
@@ -23,26 +23,6 @@ llvm::StringRef DW_TAG_value_to_name(dw_tag_t tag) {
return s_unknown_tag_name;
}
-const char *DW_AT_value_to_name(uint32_t val) {
- static char invalid[100];
- llvm::StringRef llvmstr = llvm::dwarf::AttributeString(val);
- if (llvmstr.empty()) {
-snprintf(invalid, sizeof(invalid), "Unknown DW_AT constant: 0x%x", val);
-return invalid;
- }
- return llvmstr.data();
-}
-
-const char *DW_FORM_value_to_name(uint32_t val) {
- static char invalid[100];
- llvm::StringRef llvmstr = llvm::dwarf::FormEncodingString(val);
- if (llvmstr.empty()) {
-snprintf(invalid, sizeof(invalid), "Unknown DW_FORM constant: 0x%x", val);
-return invalid;
- }
- return llvmstr.data();
-}
-
const char *DW_OP_value_to_name(uint32_t val) {
static char invalid[100];
llvm::StringRef llvmstr = llvm::dwarf::OperationEncodingString(val);
@@ -53,35 +33,5 @@ const char *DW_OP_value_to_name(uint32_t val) {
return llvmstr.data();
}
-const char *DW_ATE_value_to_name(uint32_t val) {
- static char invalid[100];
- llvm::StringRef llvmstr = llvm::dwarf::AttributeEncodingString(val);
- if (llvmstr.empty()) {
-snprintf(invalid, sizeof(invalid), "Unknown DW_ATE constant: 0x%x", val);
-return invalid;
- }
- return llvmstr.data();
-}
-
-const char *DW_LANG_value_to_name(uint32_t val) {
- static char invalid[100];
- llvm::StringRef llvmstr = llvm::dwarf::LanguageString(val);
- if (llvmstr.empty()) {
-snprintf(invalid, sizeof(invalid), "Unknown DW_LANG constant: 0x%x", val);
-return invalid;
- }
- return llvmstr.data();
-}
-
-const char *DW_LNS_value_to_name(uint32_t val) {
- static char invalid[100];
- llvm::StringRef llvmstr = llvm::dwarf::LNStandardString(val);
- if (llvmstr.empty()) {
-snprintf(invalid, sizeof(invalid), "Unknown DW_LNS constant: 0x%x", val);
-return invalid;
- }
- return llvmstr.data();
-}
-
} // namespace dwarf
} // namespace lldb_private::plugin
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h
index e87ac458fe962c..be81cb0f5df1ea 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.h
@@ -15,22 +15,10 @@
namespace lldb_private::plugin {
namespace dwarf {
-typedef uint32_t DRC_class; // Holds DRC_* class bitfields
-
llvm::StringRef DW_TAG_value_to_name(dw_tag_t tag);
-const char *DW_AT_value_to_name(uint32_t val);
-
-const char *DW_FORM_value_to_name(uint32_t val);
-
const char *DW_OP_value_to_name(uint32_t val);
-const char *DW_ATE_value_to_name(uint32_t val);
-
-const char *DW_LANG_value_to_name(uint32_t val);
-
-const char *DW_LNS_value_to_name(uint32_t val);
-
} // namespace dwarf
} // namespace lldb_private::plugin
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFCI] Unify DW_TAG -> string conversions (PR #90657)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/90657 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -85,3 +86,84 @@ def test_command_output(self):
self.assertEqual(res.GetOutput(), "")
self.assertIsNotNone(res.GetError())
self.assertEqual(res.GetError(), "")
+
+def test_structured_transcript(self):
+"""Test structured transcript generation and retrieval."""
+# Get command interpreter and create a target
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+ci = self.dbg.GetCommandInterpreter()
+self.assertTrue(ci, VALID_COMMAND_INTERPRETER)
+
+# Send a few commands through the command interpreter
+res = lldb.SBCommandReturnObject()
+ci.HandleCommand("version", res)
+ci.HandleCommand("an-unknown-command", res)
+ci.HandleCommand("breakpoint set -f main.c -l %d" % self.line, res)
+ci.HandleCommand("r", res)
+ci.HandleCommand("p a", res)
+total_number_of_commands = 5
+
+# Retrieve the transcript and convert it into a Python object
+transcript = ci.GetTranscript()
+self.assertTrue(transcript.IsValid())
+
+stream = lldb.SBStream()
+self.assertTrue(stream)
+
+error = transcript.GetAsJSON(stream)
+self.assertSuccess(error)
+
+transcript = json.loads(stream.GetData())
+
+# The transcript will contain a bunch of commands that are run
+# automatically. We only want to validate for the ones that are
+# listed above, hence trimming to the last parts.
+transcript = transcript[-total_number_of_commands:]
bulbazord wrote:
Instead of trimming, why not verify that the transcript contains exactly the
number we care about? Or is there a reason there would be more? Perhaps from
some setup code?
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
https://github.com/bulbazord commented: Looking better. Thanks for sticking with us through the review! :) https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -289,3 +290,19 @@ void
StructuredData::Null::GetDescription(lldb_private::Stream ) const {
void StructuredData::Generic::GetDescription(lldb_private::Stream ) const {
s.Printf("%p", m_object);
}
+
+StructuredData::ArraySP StructuredData::Array::SplitString(llvm::StringRef s,
+ char separator,
+ int maxSplit,
+ bool keepEmpty) {
+ // Split the string into a small vector.
+ llvm::SmallVector small_vec;
+ s.split(small_vec, separator, maxSplit, keepEmpty);
+
+ // Copy the substrings from the small vector into the output array.
+ auto array_sp = std::make_shared();
+ for (auto substring : small_vec) {
+array_sp->AddStringItem(std::move(substring));
bulbazord wrote:
nit: no need for the move, StringRefs are pretty cheap to copy
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)
@@ -13,11 +13,42 @@
#include
#include
+#include "llvm/ADT/StringSet.h"
+
namespace lldb_private {
class StreamString;
class Log;
+class FieldEnum {
+public:
+ struct Enumerator {
+uint64_t m_value;
+// Short name for the value. Shown in tables and when printing the field's
+// value. For example "RZ".
+std::string m_name;
+
+Enumerator(uint64_t value, std::string name)
+: m_value(value), m_name(name) {}
+
+void ToXML(StreamString ) const;
+ };
+
+ typedef std::vector Enumerators;
+
+ FieldEnum(std::string id, const Enumerators );
+
+ const Enumerators () const { return m_enumerators; }
+
+ const std::string () const { return m_id; }
+
+ void ToXML(StreamString , unsigned size) const;
bulbazord wrote:
Why does this take a `StreamString &` directly instead of the more general
`Stream &`?
https://github.com/llvm/llvm-project/pull/90063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)
@@ -13,11 +13,42 @@
#include
#include
+#include "llvm/ADT/StringSet.h"
+
namespace lldb_private {
class StreamString;
class Log;
+class FieldEnum {
+public:
+ struct Enumerator {
+uint64_t m_value;
+// Short name for the value. Shown in tables and when printing the field's
+// value. For example "RZ".
+std::string m_name;
+
+Enumerator(uint64_t value, std::string name)
+: m_value(value), m_name(name) {}
bulbazord wrote:
`std::move` on the name?
https://github.com/llvm/llvm-project/pull/90063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)
@@ -13,11 +13,42 @@
#include
#include
+#include "llvm/ADT/StringSet.h"
+
namespace lldb_private {
class StreamString;
class Log;
+class FieldEnum {
+public:
+ struct Enumerator {
+uint64_t m_value;
+// Short name for the value. Shown in tables and when printing the field's
+// value. For example "RZ".
+std::string m_name;
+
+Enumerator(uint64_t value, std::string name)
+: m_value(value), m_name(name) {}
+
+void ToXML(StreamString ) const;
+ };
+
+ typedef std::vector Enumerators;
+
+ FieldEnum(std::string id, const Enumerators );
+
+ const Enumerators () const { return m_enumerators; }
+
+ const std::string () const { return m_id; }
+
+ void ToXML(StreamString , unsigned size) const;
+
+private:
+ std::string m_id;
+ std::vector m_enumerators;
bulbazord wrote:
nit: Change the type to `Enumerators`?
https://github.com/llvm/llvm-project/pull/90063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -366,10 +396,10 @@ class StructuredData {
class String : public Object {
public:
String() : Object(lldb::eStructuredDataTypeString) {}
-explicit String(llvm::StringRef S)
-: Object(lldb::eStructuredDataTypeString), m_value(S) {}
+explicit String(llvm::StringRef s)
+: Object(lldb::eStructuredDataTypeString), m_value(s) {}
-void SetValue(llvm::StringRef S) { m_value = std::string(S); }
+void SetValue(llvm::StringRef s) { m_value = std::string(s); }
bulbazord wrote:
The changes to adjust the name of the variable are unnecessary and make it
harder to navigate commit history. Please revert it.
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -290,6 +290,36 @@ class StructuredData {
void GetDescription(lldb_private::Stream ) const override;
+/// Creates an Array of substrings by splitting a string around the
+/// occurrences of a separator character.
+///
+/// Note:
+/// * This is almost the same API and implementation as `StringRef::split`.
+/// * Not depending on `StringRef::split` because it will involve a
+/// temporary `SmallVectorImpl`.
bulbazord wrote:
It sounds like this is justifying duplication for efficiency reasons. Have you
actually observed that there is an actual gain in duplicating this
functionality here? If you're doing this preemptively because it sounds like it
should be faster, I would say measure or don't do it at all.
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -318,6 +318,12 @@ class SBCommandInterpreter {
SBStructuredData GetStatistics();
+ /// Returns a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys: "command" (string), "output"
+ /// (list of strings) and optionally "error" (list of strings). Each string
+ /// in "output" and "error" is a line (without EOL characteres).
bulbazord wrote:
typo: `characteres` -> `characters`
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster, CommandUsageMap m_command_usages; StreamString m_transcript_stream; + + /// Contains a list of handled commands, output and error. Each element in + /// the list is a dictionary with three keys: "command" (string), "output" + /// (list of strings) and optionally "error" (list of strings). Each string + /// in "output" and "error" is a line (without EOL characters). + StructuredData::ArraySP m_transcript_structured; bulbazord wrote: nit: No need to put `structured` in the variable name. https://github.com/llvm/llvm-project/pull/90703 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)
@@ -731,8 +747,11 @@ class Debugger : public std::enable_shared_from_this, lldb::TargetSP m_dummy_target_sp; Diagnostics::CallbackID m_diagnostics_callback_id; - lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr; - void *m_destroy_callback_baton = nullptr; + std::recursive_mutex m_destroy_callback_mutex; bulbazord wrote: Handling a callback could add or remove other callbacks, it does need to be thread safe. And as much as I dislike recursive mutex as well, is there another way you could handle those scenarios safely? https://github.com/llvm/llvm-project/pull/89868 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [debugserver] address preprocessor warning, extra arg (PR #90808)
@@ -169,25 +173,28 @@ kern_return_t DNBArchMachARM64::GetGPRState(bool force) {
(thread_state_t)_state.context.gpr, );
if (DNBLogEnabledForAny(LOG_THREAD)) {
uint64_t *x = _state.context.gpr.__x[0];
+
+#if defined(DEBUGSERVER_IS_ARM64E)
DNBLogThreaded("thread_get_state signed regs "
"\n fp=%16.16llx"
"\n lr=%16.16llx"
"\n sp=%16.16llx"
"\n pc=%16.16llx",
-#if __has_feature(ptrauth_calls) && defined(__LP64__)
reinterpret_cast(m_state.context.gpr.__opaque_fp),
reinterpret_cast(m_state.context.gpr.__opaque_lr),
reinterpret_cast(m_state.context.gpr.__opaque_sp),
- reinterpret_cast(m_state.context.gpr.__opaque_pc)
+
reinterpret_cast(m_state.context.gpr.__opaque_pc));
#else
- m_state.context.gpr.__fp,
- m_state.context.gpr.__lr,
- m_state.context.gpr.__sp,
- m_state.context.gpr.__pc
+DNBLogThreaded("thread_get_state signed regs "
+ "\n fp=%16.16llx"
+ "\n lr=%16.16llx"
+ "\n sp=%16.16llx"
+ "\n pc=%16.16llx",
+ m_state.context.gpr.__fp, m_state.context.gpr.__lr,
+ m_state.context.gpr.__sp, m_state.context.gpr.__pc);
bulbazord wrote:
Suggestion: The format string is the same between these two, why not pull out
the common factor?
```
const char *format = "thread_get_state signed regs\n fp=%16.16llx\n
lr=%16.16llx\n sp=%16.16llx\n pc=%16.16llx";
#if defined(...)
DNBLogThreaded(format, ...);
#else
DNBLogThreaded(format, ...);
#endif
```
You could also pull out the arguments.
https://github.com/llvm/llvm-project/pull/90808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
bulbazord wrote:
Hmm, thinking about this further that does make sense. CMake will create a
subdirectory in your build tree for lldb at `$BUILD_DIR/tools/lldb` and will
set `CMAKE_CURRENT_BINARY_DIR` to that subdirectory in that context. For
standalone builds, LLDB is its own standalone project, so it gets set to
`$BUILD_DIR` in that case. I think you can just set `LLDB_OBJ_DIR` to
`${CMAKE_CURRENT_BINARY_DIR}` and call it a day.
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -8,6 +8,12 @@ set(LLDB_INCLUDE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/include")
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+if (LLDB_BUILT_STANDALONE)
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LLDB_OBJ_DIR ${CMAKE_CURRENT_BINARY_DIR}/tools/lldb)
+endif()
bulbazord wrote:
LLDBConfig is included after LLDBStandalone, so that can't work right?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
https://github.com/bulbazord approved this pull request. Looks fine to me. Thanks for fixing this! https://github.com/llvm/llvm-project/pull/90666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
bulbazord wrote: I think you've laid out the events that happen nicely but I came to the opposite conclusion. I still don't think this is the right fix. We have buildbots running on x86_64 and it works there too. I don't think this test working on AArch64 machines is related. The platform architecture getting set to x86_64 makes sense to me because the ELF is built as an x86_64 binary. However, the platform_sp getting set to `host` during the creation of the Target. That seems like the bug to me, especially because we explicitly set the platform to `remote-linux` when trying to create the target. The presented solution is a small bandage to work around the underlying bug. Another way to look at it might be: If we have to set the platform to `remote-linux` ourselves after creating the target, what's the point of `SBDebugger::CreateTarget` taking a platform name as an argument? https://github.com/llvm/llvm-project/pull/90580 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Install generated API headers into LLDB.framework (PR #90666)
@@ -71,6 +71,7 @@ endif()
# At configuration time, collect headers for the framework bundle and copy them
# into a staging directory. Later we can copy over the entire folder.
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB built_public_headers
${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/../tools/lldb/include/lldb/API/*.h)
bulbazord wrote:
Yeah that is definitely incorrect for a standalone build. You could put the
directory into a CMake variable and use that instead of reconstructing it here.
Also nit: `built_public_headers` -> `generated_public_headers`?
https://github.com/llvm/llvm-project/pull/90666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFCI] Unify DW_TAG -> string conversions (PR #90657)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/90657
The high level goal is to have 1 way of converting a DW_TAG value into a
human-readable string.
There are 3 ways this change accomplishes that:
1.) Changing DW_TAG_value_to_name to not create custom error strings.
The way it was doing this is error-prone: Specifically, it was using a
function-local static char buffer and handing out a pointer to it.
Initialization of this is thread-safe, but mutating it is definitely
not. Multiple threads that want to call this function could step on
each others toes. The implementation in this patch sidesteps the issue
by just returning a StringRef with no mention of the tag value in it.
2.) Changing all uses of DW_TAG_value_to_name to log the value of the
tag since the function doesn't create a string with the value in it
anymore.
3.) Removing `DWARFBaseDIE::GetTagAsCString()`. Callers should call
DW_TAG_value_to_name on the tag directly.
>From bdcb733bcfd64e23edac44ae0a21897720084879 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Tue, 30 Apr 2024 11:30:22 -0700
Subject: [PATCH] [lldb][NFCI] Unify DW_TAG -> string conversions
The high level goal is to have 1 way of converting a DW_TAG value into a
human-readable string.
There are 3 ways this change accomplishes that:
1.) Changing DW_TAG_value_to_name to not create custom error strings.
The way it was doing this is error-prone: Specifically, it was using a
function-local static char buffer and handing out a pointer to it.
Initialization of this is thread-safe, but mutating it is definitely
not. Multiple threads that want to call this function could step on
each others toes. The implementation in this patch sidesteps the issue
by just returning a StringRef with no mention of the tag value in it.
2.) Changing all uses of DW_TAG_value_to_name to log the value of the
tag since the function doesn't create a string with the value in it
anymore.
3.) Removing `DWARFBaseDIE::GetTagAsCString()`. Callers should call
DW_TAG_value_to_name on the tag directly.
---
.../SymbolFile/DWARF/DWARFASTParserClang.cpp | 62 +-
.../Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp | 4 --
.../Plugins/SymbolFile/DWARF/DWARFBaseDIE.h | 2 -
.../Plugins/SymbolFile/DWARF/DWARFDefines.cpp | 16 ++---
.../Plugins/SymbolFile/DWARF/DWARFDefines.h | 2 +-
.../SymbolFile/DWARF/SymbolFileDWARF.cpp | 63 ++-
6 files changed, 71 insertions(+), 78 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index bea11e0e3840af..f8101aba5c6277 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -452,9 +452,9 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const
SymbolContext ,
log,
"DWARFASTParserClang::ParseTypeFromDWARF "
"(die = {0:x16}, decl_ctx = {1:p} (die "
-"{2:x16})) {3} name = '{4}')",
+"{2:x16})) {3} ({4}) name = '{5}')",
die.GetOffset(), static_cast(context), context_die.GetOffset(),
-die.GetTagAsCString(), die.GetName());
+DW_TAG_value_to_name(die.Tag()), die.Tag(), die.GetName());
}
Type *type_ptr = dwarf->GetDIEToType().lookup(die.GetDIE());
@@ -765,9 +765,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'id' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCID);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -776,9 +777,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
dwarf->GetObjectFile()->GetModule()->LogMessage(
log,
-"SymbolFileDWARF::ParseType (die = {0:x16}) {1} '{2}' "
+"SymbolFileDWARF::ParseType (die = {0:x16}) {1} ({2}) '{3}' "
"is Objective-C 'Class' built-in type.",
-die.GetOffset(), die.GetTagAsCString(), die.GetName());
+die.GetOffset(), DW_TAG_value_to_name(die.Tag()), die.Tag(),
+die.GetName());
clang_type = m_ast.GetBasicType(eBasicTypeObjCClass);
encoding_data_type = Type::eEncodingIsUID;
attrs.type.Clear();
@@ -787,9 +789,10 @@ DWARFASTParserClang::ParseTypeModifier(const SymbolContext
,
if (log)
[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)
bulbazord wrote: This doesn't actually copy `SBLanguages.h` into the framework, so this breaks the framework. These tests now fail: ``` Unresolved Tests (5): lldb-api :: api/check_public_api_headers/TestPublicAPIHeaders.py lldb-api :: api/multiple-debuggers/TestMultipleDebuggers.py lldb-api :: api/multiple-targets/TestMultipleTargets.py lldb-api :: api/multithreaded/TestMultithreaded.py lldb-api :: functionalities/plugins/command_plugin/TestPluginCommands.py ``` https://github.com/llvm/llvm-project/pull/89981 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
bulbazord wrote: LLDB changes look fine. https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Windows] Fixed unresolved test lldb-api python_api/debugger/TestDebuggerAPI.py (PR #90580)
https://github.com/bulbazord requested changes to this pull request. I don't think this is the right thing to do. `SBDebugger::CreateTarget` takes a `platform_name` argument which we're already setting to "remote-linux". If `target1.GetPlatform()` doesn't return the SBPlatform for `remote-linux` then I would think that's the actual bug. https://github.com/llvm/llvm-project/pull/90580 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix lock guads in PipePosix.cpp (PR #90572)
https://github.com/bulbazord commented: lgtm https://github.com/llvm/llvm-project/pull/90572 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)
@@ -743,9 +743,19 @@ DebuggerSP
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
}
void Debugger::HandleDestroyCallback() {
- if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+ std::lock_guard guard(m_destroy_callback_mutex);
+ const lldb::user_id_t user_id = GetID();
+ // In case one destroy callback adds or removes other destroy callbacks
+ // which aren't taken care of in the same inner loop.
+ while (m_destroy_callback_and_baton.size()) {
+auto iter = m_destroy_callback_and_baton.begin();
+while (iter != m_destroy_callback_and_baton.end()) {
+ // Invoke the callback and remove the entry from the map
+ const auto = iter->second.first;
+ const auto = iter->second.second;
+ callback(user_id, baton);
+ iter = m_destroy_callback_and_baton.erase(iter);
+}
bulbazord wrote:
Instead of your 2 loop approach, could you not just repeatedly grab and call
the first callback in the list? If new ones are added it'll be picked up, if
others are removed then the next iteration won't see them.
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)
bulbazord wrote: > > Please update the PR subject as its a lot more than just X86AsmParser.cpp > > Hi @RKSimon > > All the issues mentioned are fixed. The title of the PR is misleading. The > title is the same as the issue (#85868) it corresponds to. Got a look to > other PR's and I thought that this is the usual naming convention. Please > refer to the > [commit](https://github.com/llvm/llvm-project/pull/90391/commits/54c6c6b7d71f5ff293412f5f91e9f880480284f8) > and you will see all the modified files. Commit titles should accurately reflect a change. Your change modifies more than just X86AsmParser.cpp, so reading the commit title alone might lead one to believe that's all that changed. But it's not, you changed many things across the code base (even if the changes are all of the same kind). A more accurate title might be something like: `Add clarifying parenthesis around non-trivial conditions in ternary expressions`. https://github.com/llvm/llvm-project/pull/90391 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add ability to specify running LLDB API testsuite by json description (PR #89764)
https://github.com/bulbazord commented: This change does 2 things, both of which are quite substantial on their own. Can you break them up into two changes to make it easier to review? Higher level feedback: Please add some documentation for these new changes. The change to dotest.py is minor but a short line about it somewhere (perhaps in the test suite docs?) would be helpful. As for the JSON Config, there is documentation on common build options where this might be useful. Some feedback on the individual changes: 1) Changing dotest so that it can accept multiple things for `-E`. You solved this by inserting a special token (`start:`) that tells dotest to interpret it differently. Could you not instead change the action for `-E` to be `append`? That way E is already a list of arguments. I see that `start` is there to prevent an issue when the argument starts with `--` right? Is that an issue if you add quotes? What about if you do something like `-E "--first -Second --third"`? Does that work? 2) It looks like you're expected to pass the JSON config file into CMake which does some processing on it to fill out lit.cfg right? Does this mean I'd have to reconfigure if I change the JSON at all? I think it would be easier if we could instead teach dotest.py to read the JSON configuration. The CMake code would then either accept a user-provided JSON file or build a default one. https://github.com/llvm/llvm-project/pull/89764 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Display breakpoint locations using display name (PR #90297)
bulbazord wrote: I think your commit summary has a typo. It should say that the parameter defaults to false, not true. https://github.com/llvm/llvm-project/pull/90297 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Consult Language plugin in GetDisplayDemangledName (PR #90294)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/90294 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)
@@ -321,13 +321,22 @@ class LLDB_API SBDebugger {
void SetLoggingCallback(lldb::LogOutputCallback log_callback, void *baton);
+ /// DEPRECATED: We used to only support one Destroy callback. Now that we
+ /// support Add and Remove, you should only remove Destroy callbacks that
+ /// you Add-ed. Use Add and Remove instead.
+ ///
+ /// Clear all previously added callbacks and only add the given one.
void SetDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
bulbazord wrote:
There are some macros you can use in addition to the documentation:
`LLDB_DEPRECATED_FIXME`. This will give compiler warnings to anyone using
`SetDestroyCallback` so they can update their code.
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Switch to llvm::DWARFUnitHeader (PR #89808)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/89808 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][nfc] Move broadcaster class strings away from ConstString (PR #89690)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/89690 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix crash in SymbolFileCTF::ParseFunctions (PR #89845)
https://github.com/bulbazord approved this pull request. Makes sense to me. https://github.com/llvm/llvm-project/pull/89845 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Switch to llvm::DWARFUnitHeader (PR #89808)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/89808
These are now close enough that they can be swapped out.
>From 3f3989d3d7b0cd64a08a8c30d4d83e45098a4b44 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Tue, 23 Apr 2024 12:14:02 -0700
Subject: [PATCH] [lldb] Switch to llvm::DWARFUnitHeader
These are now close enough that they can be swapped out.
---
.../SymbolFile/DWARF/DWARFCompileUnit.h | 2 +-
.../Plugins/SymbolFile/DWARF/DWARFTypeUnit.h | 6 +-
.../Plugins/SymbolFile/DWARF/DWARFUnit.cpp| 137 +-
.../Plugins/SymbolFile/DWARF/DWARFUnit.h | 68 ++---
4 files changed, 48 insertions(+), 165 deletions(-)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
index dd130977d4b1fb..b8344f548ac3dc 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
@@ -32,7 +32,7 @@ class DWARFCompileUnit : public DWARFUnit {
private:
DWARFCompileUnit(SymbolFileDWARF , lldb::user_id_t uid,
- const DWARFUnitHeader ,
+ const llvm::DWARFUnitHeader ,
const llvm::DWARFAbbreviationDeclarationSet ,
DIERef::Section section, bool is_dwo)
: DWARFUnit(dwarf, uid, header, abbrevs, section, is_dwo) {}
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFTypeUnit.h
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFTypeUnit.h
index 7b58c632c6c5be..8c1f932d8c7fa4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFTypeUnit.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFTypeUnit.h
@@ -24,15 +24,15 @@ class DWARFTypeUnit : public DWARFUnit {
void Dump(Stream *s) const override;
- uint64_t GetTypeHash() { return m_header.GetTypeHash(); }
+ uint64_t GetTypeHash() { return m_header.getTypeHash(); }
- dw_offset_t GetTypeOffset() { return GetOffset() + m_header.GetTypeOffset();
}
+ dw_offset_t GetTypeOffset() { return GetOffset() + m_header.getTypeOffset();
}
static bool classof(const DWARFUnit *unit) { return unit->IsTypeUnit(); }
private:
DWARFTypeUnit(SymbolFileDWARF , lldb::user_id_t uid,
-const DWARFUnitHeader ,
+const llvm::DWARFUnitHeader ,
const llvm::DWARFAbbreviationDeclarationSet ,
DIERef::Section section, bool is_dwo)
: DWARFUnit(dwarf, uid, header, abbrevs, section, is_dwo) {}
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index e28036d34b34a6..dabc595427dfa1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -33,12 +33,12 @@ using namespace lldb_private::plugin::dwarf;
extern int g_verbose;
DWARFUnit::DWARFUnit(SymbolFileDWARF , lldb::user_id_t uid,
- const DWARFUnitHeader ,
+ const llvm::DWARFUnitHeader ,
const llvm::DWARFAbbreviationDeclarationSet ,
DIERef::Section section, bool is_dwo)
: UserID(uid), m_dwarf(dwarf), m_header(header), m_abbrevs(),
m_cancel_scopes(false), m_section(section), m_is_dwo(is_dwo),
- m_has_parsed_non_skeleton_unit(false), m_dwo_id(header.GetDWOId()) {}
+ m_has_parsed_non_skeleton_unit(false), m_dwo_id(header.getDWOId()) {}
DWARFUnit::~DWARFUnit() = default;
@@ -345,7 +345,7 @@ void DWARFUnit::ExtractDIEsRWLocked() {
void DWARFUnit::SetDwoStrOffsetsBase() {
lldb::offset_t baseOffset = 0;
- if (const llvm::DWARFUnitIndex::Entry *entry = m_header.GetIndexEntry()) {
+ if (const llvm::DWARFUnitIndex::Entry *entry = m_header.getIndexEntry()) {
if (const auto *contribution =
entry->getContribution(llvm::DW_SECT_STR_OFFSETS))
baseOffset = contribution->getOffset();
@@ -489,7 +489,7 @@ ParseListTableHeader(const llvm::DWARFDataExtractor ,
uint64_t offset,
void DWARFUnit::SetLoclistsBase(dw_addr_t loclists_base) {
uint64_t offset = 0;
- if (const llvm::DWARFUnitIndex::Entry *entry = m_header.GetIndexEntry()) {
+ if (const llvm::DWARFUnitIndex::Entry *entry = m_header.getIndexEntry()) {
const auto *contribution = entry->getContribution(llvm::DW_SECT_LOCLISTS);
if (!contribution) {
GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
@@ -533,7 +533,7 @@ DWARFDataExtractor DWARFUnit::GetLocationData() const {
DWARFContext = GetSymbolFileDWARF().GetDWARFContext();
const DWARFDataExtractor =
GetVersion() >= 5 ? Ctx.getOrLoadLocListsData() : Ctx.getOrLoadLocData();
- if (const llvm::DWARFUnitIndex::Entry *entry = m_header.GetIndexEntry()) {
+ if (const llvm::DWARFUnitIndex::Entry *entry = m_header.getIndexEntry()) {
if (const auto *contribution = entry->getContribution(
GetVersion() >= 5 ? llvm::DW_SECT_LOCLISTS :
llvm::DW_SECT_EXT_LOC))
[Lldb-commits] [lldb] [lldb] Add SB API to access static constexpr member values (PR #89730)
@@ -325,6 +330,79 @@ lldb::SBTypeMemberFunction
SBType::GetMemberFunctionAtIndex(uint32_t idx) {
return sb_func_type;
}
+SBTypeStaticField::SBTypeStaticField() { LLDB_INSTRUMENT_VA(this); }
+
+SBTypeStaticField::SBTypeStaticField(lldb_private::CompilerDecl decl)
+: m_opaque_up(decl ? std::make_unique(decl) : nullptr) {}
+
+SBTypeStaticField::SBTypeStaticField(const SBTypeStaticField ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBTypeStaticField ::operator=(const SBTypeStaticField ) {
+ LLDB_INSTRUMENT_VA(this, rhs);
+
+ m_opaque_up = clone(rhs.m_opaque_up);
+ return *this;
+}
+
+SBTypeStaticField::~SBTypeStaticField() { LLDB_INSTRUMENT_VA(this); }
+
+SBTypeStaticField::operator bool() const {
+ LLDB_INSTRUMENT_VA(this);
+
+ return IsValid();
+}
+
+bool SBTypeStaticField::IsValid() const {
+ LLDB_INSTRUMENT_VA(this);
+
+ return m_opaque_up != nullptr;
+}
+
+const char *SBTypeStaticField::GetName() {
+ LLDB_INSTRUMENT_VA(this);
+
+ if (!IsValid())
+return "";
+ return m_opaque_up->GetName().GetCString();
+}
+
+const char *SBTypeStaticField::GetMangledName() {
+ LLDB_INSTRUMENT_VA(this);
+
+ if (!IsValid())
+return "";
+ return m_opaque_up->GetMangledName().GetCString();
+}
+
+SBType SBTypeStaticField::GetType() {
+ LLDB_INSTRUMENT_VA(this);
+
+ if (!IsValid())
+return SBType();
+ return SBType(m_opaque_up->GetType());
+}
+
+SBValue SBTypeStaticField::GetConstantValue(lldb::SBTarget target) {
+ LLDB_INSTRUMENT_VA(this);
bulbazord wrote:
The instrumentation macro is missing `target`.
https://github.com/llvm/llvm-project/pull/89730
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][nfc] Move broadcaster class strings away from ConstString (PR #89690)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/89690
These are hardcoded strings that are already present in the data section of the
binary, no need to immediately place them in the ConstString StringPools. Lots
of code still calls `GetBroadcasterClass` and places the return value into a
ConstString. Changing that would be a good follow-up.
Additionally, calls to these functions are still wrapped in ConstStrings at the
SBAPI layer. This is because we must guarantee the lifetime of all strings
handed out publicly.
>From 406ce4dc0151cf1afdc3ab0fa7b8743029b869f3 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Mon, 22 Apr 2024 17:07:57 -0700
Subject: [PATCH] [lldb][nfc] Move broadcaster class strings away from
ConstString
These are hardcoded strings that are already present in the data section
of the binary, no need to immediately place them in the ConstString
StringPools. Lots of code still calls `GetBroadcasterClass` and places
the return value into a ConstString. Changing that would be a good
follow-up.
Additionally, calls to these functions are still wrapped in ConstStrings
at the SBAPI layer. This is because we must guarantee the lifetime of
all strings handed out publicly.
---
lldb/include/lldb/Core/Debugger.h | 2 +-
lldb/include/lldb/Core/ThreadedCommunication.h | 4 ++--
lldb/include/lldb/Interpreter/CommandInterpreter.h | 4 ++--
lldb/include/lldb/Target/Process.h | 4 ++--
lldb/include/lldb/Target/Target.h | 4 ++--
lldb/include/lldb/Target/TargetList.h | 4 ++--
lldb/include/lldb/Target/Thread.h | 4 ++--
lldb/include/lldb/Utility/Broadcaster.h| 8
lldb/source/API/SBCommandInterpreter.cpp | 3 ++-
lldb/source/API/SBCommunication.cpp| 3 ++-
lldb/source/API/SBDebugger.cpp | 2 +-
lldb/source/API/SBEvent.cpp| 3 ++-
lldb/source/API/SBProcess.cpp | 4 ++--
lldb/source/API/SBTarget.cpp | 2 +-
lldb/source/API/SBThread.cpp | 2 +-
lldb/source/Core/Debugger.cpp | 6 +++---
lldb/source/Core/ThreadedCommunication.cpp | 4 ++--
lldb/source/Interpreter/CommandInterpreter.cpp | 6 +++---
lldb/source/Target/Process.cpp | 6 +++---
lldb/source/Target/Target.cpp | 6 +++---
lldb/source/Target/TargetList.cpp | 6 +++---
lldb/source/Target/Thread.cpp | 6 +++---
lldb/source/Utility/Broadcaster.cpp| 4 ++--
23 files changed, 50 insertions(+), 47 deletions(-)
diff --git a/lldb/include/lldb/Core/Debugger.h
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f4..49ff0737acef82 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -89,7 +89,7 @@ class Debugger : public
std::enable_shared_from_this,
using DebuggerList = std::vector;
- static ConstString GetStaticBroadcasterClass();
+ static llvm::StringRef GetStaticBroadcasterClass();
/// Get the public broadcaster for this debugger.
Broadcaster () { return m_broadcaster; }
diff --git a/lldb/include/lldb/Core/ThreadedCommunication.h
b/lldb/include/lldb/Core/ThreadedCommunication.h
index 7ebb77beb77f3d..24412b2027932d 100644
--- a/lldb/include/lldb/Core/ThreadedCommunication.h
+++ b/lldb/include/lldb/Core/ThreadedCommunication.h
@@ -216,9 +216,9 @@ class ThreadedCommunication : public Communication, public
Broadcaster {
///
void SynchronizeWithReadThread();
- static ConstString ();
+ static llvm::StringRef GetStaticBroadcasterClass();
- ConstString () const override {
+ llvm::StringRef GetBroadcasterClass() const override {
return GetStaticBroadcasterClass();
}
diff --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index d190bcdcab4497..70a55a77465bfe 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -255,9 +255,9 @@ class CommandInterpreter : public Broadcaster,
// These two functions fill out the Broadcaster interface:
- static ConstString ();
+ static llvm::StringRef GetStaticBroadcasterClass();
- ConstString () const override {
+ llvm::StringRef GetBroadcasterClass() const override {
return GetStaticBroadcasterClass();
}
diff --git a/lldb/include/lldb/Target/Process.h
b/lldb/include/lldb/Target/Process.h
index 2f3a3c22422efe..aac0cf51680a9e 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -381,7 +381,7 @@ class Process : public
std::enable_shared_from_this,
// These two functions fill out the Broadcaster interface:
- static ConstString ();
+ static llvm::StringRef GetStaticBroadcasterClass();
static constexpr llvm::StringRef
[Lldb-commits] [lldb] [easy] Fix spacing in help message of 'process save-core' command (PR #89445)
https://github.com/bulbazord approved this pull request. LGTM. Thanks! https://github.com/llvm/llvm-project/pull/89445 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Skip remote PutFile when MD5 hashes equal (PR #88812)
bulbazord wrote: > I got an email that the build failed and I should revert because of this: > https://lab.llvm.org/buildbot/#/builders/68/builds/72623 > > @bulbazord can you or someone with write permissions revert this PR so I have > time to triage the issue? As David said, no need since that was unrelated to your change. Jonas makes a good point in his review though (that I totally missed when I reviewed), please open a new PR that addresses his feedback. https://github.com/llvm/llvm-project/pull/88812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext (PR #89324)
@@ -848,9 +848,18 @@ SymbolFileDWARFDebugMap::ResolveSymbolContext(const
Address _so_addr,
debug_map_entry->data.GetOSOFileAddress();
Address oso_so_addr;
if (oso_module->ResolveFileAddress(oso_file_addr, oso_so_addr)) {
- resolved_flags |=
- oso_module->GetSymbolFile()->ResolveSymbolContext(
- oso_so_addr, resolve_scope, sc);
+ SymbolFile *sym_file = oso_module->GetSymbolFile();
+ if (sym_file) {
bulbazord wrote:
suggestion: `if (SymbolFile *sym_file = oso_module->GetSymbolFile()) {`
https://github.com/llvm/llvm-project/pull/89324
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext (PR #89324)
https://github.com/bulbazord edited https://github.com/llvm/llvm-project/pull/89324 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext (PR #89324)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/89324 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Skip remote PutFile when MD5 hashes equal (PR #88812)
https://github.com/bulbazord closed https://github.com/llvm/llvm-project/pull/88812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Skip remote PutFile when MD5 hashes equal (PR #88812)
bulbazord wrote: > Someone will have to merge for me because it says "Only those with write > access to this repository can merge pull requests." > > Am I supposed to request write access somewhere before making these PRs? I > haven't contributed before. First time contributors aren't expected to have commit access, so no worries there. I approved it so I can land this change for you. Let's keep an eye on the build bots in case this inadvertently introduces any regressions. :) https://github.com/llvm/llvm-project/pull/88812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
