@@ -55,16 +56,33 @@ class LLDB_API SBDebugger {
eBroadcastBitExternalProgressCategory =
lldb::DebuggerBroadcastBit::eBroadcastBitExternalProgressCategory,
};
+
+ /// Default constructor creates an invalid SBDebugger instance.
SBDebugger();
SBDebugger(cons
@@ -55,16 +56,33 @@ class LLDB_API SBDebugger {
eBroadcastBitExternalProgressCategory =
lldb::DebuggerBroadcastBit::eBroadcastBitExternalProgressCategory,
};
+
+ /// Default constructor creates an invalid SBDebugger instance.
SBDebugger();
SBDebugger(cons
@@ -106,44 +124,122 @@ class LLDB_API SBDebugger {
bool &is_debugger_specific);
#endif
+ /// Get structured progress data from an event.
+ ///
+ /// \param [in] event
+ /// The event to extract the progress information from.
+ /
@@ -106,44 +124,116 @@ class LLDB_API SBDebugger {
bool &is_debugger_specific);
#endif
+ /// Get progress data from an event.
+ ///
+ /// \param [in] event
+ /// The event to extract the progress information from.
+ ///
+ /// \
@@ -55,16 +56,33 @@ class LLDB_API SBDebugger {
eBroadcastBitExternalProgressCategory =
lldb::DebuggerBroadcastBit::eBroadcastBitExternalProgressCategory,
};
+
+ /// Default constructor creates an invalid SBDebugger instance.
SBDebugger();
SBDebugger(cons
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/147621
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
I don't want to hold this up. Made some suggestions on how I would condense the
descriptions. I stopped after I realized I'd be rewriting most of these. I also
haven't checked how would the formatted version of this look like. I'll leave
it
https://github.com/labath approved this pull request.
Cool, thanks.
I'm not totally sure about our ability to break on symbols with no debug info
on all platforms (particularly, windows). If this fails somewhere, you can use
work around this by putting a breakpoint in a file with debug info, t
labath wrote:
@cmtice
https://github.com/llvm/llvm-project/pull/147955
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
No debug info in the currently selected frame. Or at least, I think so, based
on looking at the code you're fixing. You can verify that by checking whether
the current code crashes in that scenario. I'm right, it should be sufficient
to build one file with -g0.
`symbols.enable-e
labath wrote:
It's pretty much an accident we hit this in the test suite. Could you create a
dedicated test for this. I guess the scenario is "running 'frame var' in a
frame without debug info" (?)
https://github.com/llvm/llvm-project/pull/147955
___
labath wrote:
That's correct, and my earlier question basically was what if we make
`CreateHostNativeRegisterContextLinux` return
`NativeRegisterContextLinux_arm64` for arm-on-arm64 debugging. Given that
you're copying a part of _arm64 into _arm32, I am wondering whether the
arm-on-arm64 cas
labath wrote:
> > but I can also imagine doing something like python's "arbitrary width"
> > integers.
>
> Isn't this basically `llvm::APInt` class?
Sort of, but not quite. APInt has an arbitrary but fixed width. Python integers
scale their width dynamically to fit the result (so they sort of
labath wrote:
There are a couple of failures in the CI. The backtraces don't make a whole lot
sense, but it looks like there's something wrong with retrieving the list of
variables from a CU.
https://github.com/llvm/llvm-project/pull/147887
___
lldb-
labath wrote:
Personally, I'd be fine with saying that anytime we start doing arithmetic on
something (maybe, whenever we do a lvalue-to-rvalue conversion?) we switch to a
"DIL" type system. We could make that "type system" work mostly like C, but I
can also imagine doing something like python
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147525
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147701
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147704
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147680
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
We could, but I'm not sure if that's the most important question right now. The
whole BasicType concept is very C-like. There is no "unsigned long long" basic
type in swift (or pretty much any other language). While you could say that the
function returns the langauge's equivalen
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147617
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
Oooh, sweet.
https://github.com/llvm/llvm-project/pull/147617
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
I guess this one is a mistake.
https://github.com/llvm/llvm-project/pull/147563
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147563
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147529
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> But libc++ and libstdc++ print it as "abcd" (which seems like the more
> correct thing to do?)
I'm not so sure about that. std::string has a separate length field and it can
contain embedded nul characters, so I can at least understand the idea of
trusting the length field mo
labath wrote:
> > Sorry for going off-topic, but what does this say about the support for
> > `i386-apple-*` as a whole? I find the prospect of dropping that exciting,
> > as I believe that is the only target where eh_ and debug_frame register
> > numbers are different.
>
> I think we can rem
https://github.com/labath commented:
I'm not very fond of the amount of validity checks this PR is adding. What's up
with that? Is it somehow related to you passing a non-nullptr-but-uninitialized
Connection object (`std::make_unique()`) into the
AdbClient? Any chance to get rid of that? Maybe
@@ -665,3 +655,40 @@ Status
AdbClient::SyncService::PullFileChunk(std::vector &buffer,
Status AdbClient::SyncService::ReadAllBytes(void *buffer, size_t size) {
return ::ReadAllBytes(*m_conn, buffer, size);
}
+
+Status AdbClient::SyncService::SetupSyncConnection(const std::st
@@ -241,6 +234,10 @@ Status AdbClient::SendDeviceMessage(const std::string
&packet) {
Status AdbClient::ReadMessage(std::vector &message) {
message.clear();
+ if (!m_conn) {
labath wrote:
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simp
@@ -580,17 +564,23 @@ bool AdbClient::SyncService::IsConnected() const {
return m_conn && m_conn->IsConnected();
}
-AdbClient::SyncService::SyncService(std::unique_ptr &&conn)
-: m_conn(std::move(conn)) {}
+AdbClient::SyncService::SyncService(std::unique_ptr conn, const
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/145382
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/147340
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -19,6 +19,11 @@ namespace formatters {
bool GenericOptionalSummaryProvider(ValueObject &valobj, Stream &stream,
const TypeSummaryOptions &options);
+/// Return the ValueObjectSP of the underlying pointer member whose type
+/// is a desuga
https://github.com/labath approved this pull request.
I find `Generic.h` a bit... generic, but it's there, so ship it.
https://github.com/llvm/llvm-project/pull/147340
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/labath approved this pull request.
FWIW, I don't find `(null)` nor `Summary Unavailable` particularly good
summaries for `(std::string*)NULL`. At least in Python, I believe that
returning an empty string from the summary provider causes lldb to treat it as
not present and sh
https://github.com/labath approved this pull request.
This looks good. The problem with caching is not related to this patch.
> For now i think I'll probably i'll reset the formatters in the teardown hook,
> but @jimingham comment on #110767 might be a good follow-up:
>
> > Since this is just
@@ -65,15 +66,21 @@ class PipeEvent : public MainLoopWindows::IOEvent {
}
void WillPoll() override {
-if (!m_monitor_thread.joinable())
- m_monitor_thread = std::thread(&PipeEvent::Monitor, this);
+// If the m_event is signaled, wait until it is consumed befor
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/147438
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
Thanks. I like how this means we no longer create the thread lazily.
I think I see one more race, see inline comment. LGTM assuming you agree with
my analysis.
https://github.com/llvm/llvm-project/pull/147438
___
@@ -110,6 +117,7 @@ class PipeEvent : public MainLoopWindows::IOEvent {
continue;
}
+ ResetEvent(m_ready);
SetEvent(m_event);
labath wrote:
I think there's still a race here where if `WillPoll` runs between these two
calls, it will
labath wrote:
I'm not entirely comfortable with putting the (obviously c++ specific) helper
function into the DataFormatters) library. There's no reason to call this from
outside the c++ language plugin, right? What would you say to putting this into
some header inside the plugin (or creating
https://github.com/labath approved this pull request.
Cool. Thanks for looking into this.
https://github.com/llvm/llvm-project/pull/147283
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
https://github.com/labath commented:
Looking up global variables is not completely ideal (can be slow and look up
unrelated things). Would index_obj.GetValueAs**Signed**() == -1 work by any
chance?
https://github.com/llvm/llvm-project/pull/147283
___
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147141
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Your analysis is correct -- the kernel uses the bitwidth of the tracer (not the
tracee) when deciding whether to use the compatibility interface. However,
copying the code sounds like a fairly fragile solution. It'd be better to
figure out a way to share the code somehow.
The x8
https://github.com/labath commented:
(the failures are due to non-existence of formatter for
`__gnu_debug::_Safe_iterator`. It looks like that's just a wrapper around
`_Rb_tree_iterator`, so it might be easy to implement, but it's definitely not
required (skip that part of the test?)
https://
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147174
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147166
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
Ah, I see you've done that already.
Not required, but I noticed that the pointer child still contains the goo:
```
(lldb) v a.__ptr_
(std::shared_ptr::element_type *) a.__ptr_ = 0xa2b8
```
If we do the casting centrally, we could
labath wrote:
It looks like the libstdc++ test just crashes.
https://github.com/llvm/llvm-project/pull/147175
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
There are two failures:
- the libc++ pointer child is called `__ptr_`, not `pointer`. I think we should
clone/rename the child so that the child has a consistent name. This could be
particularly useful for writing other data formatters, which may want to
dereference a shared_ptr
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147139
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
I see we already have some C++ stuff in this file, but given that there really
isn't anything specific in this function, maybe we could also drop the Cxx part
from the name (maybe call it `ContainerSizeSummaryProvider `)?
https://github.com
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147137
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -150,3 +150,84 @@ TEST(ListenerTest, StartStopListeningForEventSpec) {
ASSERT_EQ(event_sp->GetBroadcaster(), &broadcaster1);
ASSERT_FALSE(listener_sp->GetEvent(event_sp, std::chrono::seconds(0)));
}
+
+TEST(ListenerTest, MoveEventsOnHijackAndRestore) {
+ Broadcaster bro
https://github.com/labath approved this pull request.
That's pretty much what I had in mind. Thanks.
https://github.com/llvm/llvm-project/pull/144919
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/144919
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
(The test is failing due to std::make_unique not being defined. I'd be fine
both with bringing back -std=c++14 and using explicit construction.)
https://github.com/llvm/llvm-project/pull/147031
___
lldb-commits mailing list
lldb-commits@
labath wrote:
> It turns out the libstdc++ formatter supports dereferencing using the
> "object" or "obj" names.
I don't think there's any harm in supporting those, though I'd be surprised if
many people are aware of that functionality. I kind of like this "hidden child"
concept, but it feels
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147031
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,7 +1,5 @@
CXX_SOURCES := main.cpp
-USE_LIBCPP := 1
-
# We need debug info tuning for lldb in order to emit the preferred name for
# std::string. See https://reviews.llvm.org/D145803.
CXXFLAGS_EXTRAS := -std=c++14 -glldb
labath wrote:
Good idea.
https
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/147054
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1077,7 +1077,8 @@ uint32_t DWARFUnit::GetHeaderByteSize() const { return
m_header.getSize(); }
std::optional
DWARFUnit::GetStringOffsetSectionItem(uint32_t index) const {
- lldb::offset_t offset = GetStrOffsetsBase() + index * 4;
+ lldb::offset_t offset =
+ GetStrO
https://github.com/labath commented:
Could use a test case.
https://github.com/llvm/llvm-project/pull/147054
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
Looks good, but you should add a unit test for the moving functionality. You
know, things like: queue, some events, hijack them, make sure they're received
at the new listener, and vice versa.
https://github.com/llvm/llvm-project/pull/144919
___
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/147033
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
Looks good modulo the failure in the libstdc++ version. The type name comes out
different, presumably because libstdc++ doesn't contain the magic to print the
template as std::string.
Testing string name printing is not really relevant for the unique_ptr
f
labath wrote:
> > the request will be expression="char*foo", which won't evaluate correctly
> > in lldb.
>
> We could search starting from the back for the first occurrence of either "&"
> or "*". I think `llvm::StringRef::find_last_of()` does this.
That's rather specific to C. In Swift for i
labath wrote:
It cannot. However, the MCP connection is done locally (on the machine running
lldb). You could argue `@skipIfRemote` is still a good thing because remote
testing is not useful here (you could use the protocol to drive a remote debug
session, but for most purposes the two session
labath wrote:
> This removes the need to pass flags (which is not a design decision I like
> but I didn't see many alternatives). @labath any opposition to putting
> everything in mem64?
I don't have an opinion on that. I'm not currently involved in minidumps.
What I am not excited about is t
https://github.com/labath approved this pull request.
Looks good. Just noting I'm kind of surprised that these pointers have a
weak_count of 1. I see it's a preexisting issue, and it may make sense if you
know the implementation, but as a user, I'm surprised.
https://github.com/llvm/llvm-proje
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/146909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -55,6 +55,12 @@ void AddFilter(TypeCategoryImpl::SharedPointer category_sp,
std::optional ExtractIndexFromString(const char *item_name);
+/// Returns \c false if the smart pointer formatters shouldn't continue
+/// formatting the rest of the object. Currently this is the c
@@ -126,3 +126,25 @@
lldb_private::formatters::GetArrayAddressOrPointerValue(ValueObject &valobj) {
return data_addr.address;
}
+
+bool lldb_private::formatters::DumpCxxSmartPtrPointerSummary(
+Stream &stream, ValueObject &ptr, const TypeSummaryOptions &options) {
+ if
@@ -0,0 +1,40 @@
+#include
+#include
+#include
+typedef std::vector int_vect;
+typedef std::vector string_vect;
+
+template
+void by_ref_and_ptr(std::vector &ref, std::vector *ptr) {
+ // Stop here to check by ref
+ return;
+}
+
+int main() {
+ int_vect numbers;
+ (numbers
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146885
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146882
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146873
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146843
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> Huh I'm surprised that's what it looks like for libc++ tbh. Not sure what our
> formatter is doing.
No, that was the raw output. I was just putting it there to show that the
libstdc++ output (where we only have the raw output) isn't that bad, which
reduces the motivation to ha
@@ -42,12 +42,15 @@ typedef void *rwlock_t;
typedef void *process_t; // Process type is HANDLE
typedef void *thread_t; // Host thread type
typedef void *file_t; // Host file type
-typedef unsigned in
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146867
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Btw, I've recently learned that synthetic child providers don't have to provide
just children. They can also provide "values" of the object (`get_value` in
python, I don't know how it's surfaced in c++). std::atomic would be a prime
candidate for that.. just in case you're intere
labath wrote:
The libstdc++ test fails. Maybe we don't even have a formatter for std::atomic
there? It currently looks like:
```
(std::atomic) i = {
std::__atomic_base = {
_M_i = 47
}
}
```
.. which isn't that bad. Much better than libc++'s
```
(std::__1::atomic) i = {
std::__1::__atom
labath wrote:
I think you're looking for `@skipIf(hostoslist=["windows"])`
https://github.com/llvm/llvm-project/pull/146807
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -42,12 +42,15 @@ typedef void *rwlock_t;
typedef void *process_t; // Process type is HANDLE
typedef void *thread_t; // Host thread type
typedef void *file_t; // Host file type
-typedef unsigned in
labath wrote:
> For some reason we have SBProcess::GetNumSupportedHardwareWatchpoints but not
> SBProcess::GetNumSupportedHardwareBreakpoints.
Just noting that the values returned from these (partially imaginary) APIs
would be hard to use correctly. The two resources might be inter-dependent.
labath wrote:
> I suppose could also approach this from the other side and look and see if we
> can get this from lldb somehow. Maybe there is enough information that we
> could determine from the debugger itself which parts of the file are
> expressions and we could make a custom request in l
https://github.com/labath approved this pull request.
This has bothered me as well.
https://github.com/llvm/llvm-project/pull/146784
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Thanks for taking this on.
It looks like most of the new tests fail on libstdc++. The reasons are often
trivial -- for example the shared_ptr test fails because the object has a
children whose name is `pointer` and not `__ptr_` (I'd say the libstdc++
formatter is right here) Ove
https://github.com/labath approved this pull request.
Sorry, I was out yesterday.
I think this is an okay, though not really satisfying solution (it could be you
resized the window to see more of your history). To see if we can handle this
uniformly, I guess we'd need to start by cataloguing t
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146554
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/146557
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/146500
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> I was running my tests in `Release` mode, so I missed that one of the
> `assert` calls had an invalid variable name. Fixed in
> [a79404e](https://github.com/llvm/llvm-project/commit/a79404e50cf5308bb76cc4eaf36cb8eaea9ab66a)
I recommend `cmake -DLLVM_ENABLE_ASSERTIONS=On` :)
ht
1 - 100 of 4672 matches
Mail list logo
