@@ -167,3 +167,49 @@ The result of this is that:
Your VM configuration should have ports ``54321`` and ``49140`` forwarded for
this to work.
+
+QEMU user mode emulation
+
+
+Serious testing of LLDB should be done using system mode emulation. The
follow
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/149057
___
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/149088
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
It looks like this just barely didn't make it into the 21.x release branch. Do
we want to cherry-pick that over? I think it would be a good way to flush out
any issues...
https://github.com/llvm/llvm-project/pull/147887
___
lldb-commits
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/148738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -73,6 +73,97 @@ TEST(NativeProcessProtocolTest, SetBreakpointFailVerify) {
llvm::Failed());
}
+TEST(NativeProcessProtocolTest, RemoveSoftwareBreakpoint) {
+ NiceMock DummyDelegate;
+ MockProcess Process(DummyDelegate,
+
https://github.com/labath approved this pull request.
Thanks.
https://github.com/llvm/llvm-project/pull/148738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Just to throw a couple of other ideas:
- write a unit test for the instruction emulator (other architectures have one)
- extend yaml2obj to work on core files
- use minidumps which are supported in yaml2obj (for unwind plan
generation/instruction emulation to work, you don't actual
labath wrote:
I'm pretty sure that's because anonymous namespaces are [printed
differently](https://godbolt.org/z/hMn6Gq46P) on windows.
https://github.com/llvm/llvm-project/pull/148940
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/
@@ -249,6 +250,41 @@ static unsigned GetCXXMethodCVQuals(const DWARFDIE
&subprogram,
return cv_quals;
}
+// TODO:
+// 0. Adjust FindInSymbols
+// 1. log failure paths
+// 2. What happens for functions without a linkage name? Previously we didn't
+// attach a label for those
labath wrote:
You should be able to extend the unit test in
unittests/Host/NativeProcessProtocolTest.cpp to cover this scenario.
https://github.com/llvm/llvm-project/pull/148738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.l
https://github.com/labath approved this pull request.
:crossed_fingers:
https://github.com/llvm/llvm-project/pull/147887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,8 +1,3 @@
-// Evil hack: To simulate memory corruption, we want to fiddle with some
internals of std::list.
labath wrote:
It looks like this test doesn't actually circularize the list anymore, so you
might as well delete it completely. Alternatively, we c
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/148285
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
> Side-note, I'm also a bit wary of all the cycle-detection stuff. Might be a
> remnant of protection against old libcxx bugs? We don't really do this stuff
> for other libcxx containers.
We don't do that for other containers, but it's not really as acute
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/148600
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
I gave this patch a spin on a mac. The only failure I got was in
test/Shell/SymbolFile/DWARF/TestDedupWarnings.test, which fails it does not
generate both of the warnings, and that's because the "p" (aka dwim-print) now
resolves to "frame var" instead of expr". Changing the test
@@ -7,127 +7,80 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper.
@@ -7,163 +7,122 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper
@@ -7,163 +7,122 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper
@@ -56,40 +84,88 @@ bool fromJSON(const llvm::json::Value &V, JSONTestType &T,
llvm::json::Path P) {
} // namespace
TEST_F(HTTPDelimitedJSONTransportTest, MalformedRequests) {
- std::string malformed_header = "COnTent-LenGth: -1{}\r\n\r\nnotjosn";
+ std::string malformed_he
@@ -7,163 +7,122 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper
@@ -7,163 +7,122 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper
@@ -22,8 +23,28 @@ class TransportBase : public PipePairTest {
protected:
std::unique_ptr to_dap;
std::unique_ptr from_dap;
+ lldb_private::MainLoop loop;
void SetUp() override;
+
+ template
+ void
+ RunOnce(std::function)> callback,
+ std::chrono::millis
@@ -7,163 +7,122 @@
//===--===//
#include "lldb/Host/JSONTransport.h"
-#include "lldb/Utility/IOObject.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
-#include "lldb/Utility/SelectHelper
@@ -737,6 +738,11 @@ class LLDB_API SBTarget {
lldb::SBBreakpoint BreakpointCreateBySBAddress(SBAddress &address);
+ lldb::SBBreakpoint
+ BreakpointCreateByFileAddress(const SBFileSpec &file_spec, addr_t file_addr,
+addr_t offset = 0,
+
@@ -84,3 +84,100 @@ TEST(DWARF64UnitTest, DWARF64DebugInfoAndCU) {
ASSERT_TRUE(declaration.IsValid());
ASSERT_EQ(declaration.Tag(), DW_TAG_subprogram);
}
+
+TEST(DWARF64UnitTest, DWARF5StrTable) {
+ const char *yamldata = R"(
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+
https://github.com/labath approved this pull request.
Cool. Thanks.
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 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
labath wrote:
I'm not sure what to add. The stripping change still seems very
language-specific to me, but I also don't have any good ideas on what to
replace it with. Maybe we could look for a sequence of identifier-like
characters (under the assumption those are roughly the same all language
@@ -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
___
1 - 100 of 4702 matches
Mail list logo
