labath wrote:
> If we are worried about supporting older uses of path expressions while we're
> quite dramatically expanding what you can express in this syntax, we probably
> should make the parser have a mode where it emulates the old path expression,
> turning off the new operators.
FTR, I
labath wrote:
> Are these actually different on Mac? These 4 are the same on BSD to my
> knowledge.
I haven't checked, I guess these four might be the same on a mac, but that
definitely is not the case everywhere. We're currently growing AIX support, and
that one seems to have different numbe
labath wrote:
Ummm... I should have caught this before, but this isn't correct because the
host system may (and some do) use different signal numbers for these constants.
So, on windows, you get an undefined symbol error, but on e.g. macos, you'd
just get a wrong value. You should take these
labath wrote:
Using a named struct now. I think it worked out pretty well. One thing you
can't do (without additional goo) with this struct is to use `std::tie` to
decompose it, but I think I managed to refactor stuff so that this is not
needed.
https://github.com/llvm/llvm-project/pull/14179
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/141799
>From bbef9674f7e5cf9fbc488e27dfd0e35fed23608a Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Wed, 28 May 2025 18:25:46 +0200
Subject: [PATCH 1/2] [lldb] Refactor away UB in SBValue::GetLoadAddress
The proble
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/141670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -27,6 +27,30 @@
#ifndef SEGV_CPERR
#define SEGV_CPERR 10
#endif
+#ifndef SI_QUEUE
+#define SI_QUEUE -1
+#endif
+#ifndef SI_TIMER
+#define SI_TIMER -2
+#endif
+#ifndef SI_MESGQ
+#define SI_MESGQ -3
+#endif
+#ifndef SI_ASYNCIO
+#define SI_ASYNCIO -4
+#endif
+#ifndef SI_SIGIO
+
@@ -557,34 +557,3 @@ ELFLinuxPrPsInfo::Populate(const
lldb_private::ProcessInstanceInfo &info,
*(psargs - 1) = '\0';
return prpsinfo;
}
-
-Status ELFLinuxSigInfo::Parse(const DataExtractor &data, const ArchSpec &arch,
labath wrote:
I'd expect you also nee
@@ -188,7 +188,74 @@ AddressClass ObjectFileXCOFF::GetAddressClass(addr_t
file_addr) {
return AddressClass::eUnknown;
}
-void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
+lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type sym_type) {
+ if (sym_type == ll
@@ -62,7 +62,7 @@ def test_subscript(self):
self.expect(
"frame var 'int_arr[-1]'",
error=True,
-substrs=["unrecognized token"],
+substrs=["failed to parse integer constant"],
labath wrote:
This is more o
@@ -188,7 +188,74 @@ AddressClass ObjectFileXCOFF::GetAddressClass(addr_t
file_addr) {
return AddressClass::eUnknown;
}
-void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
+lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type sym_type) {
+ if (sym_type == ll
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/141577
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -188,7 +188,74 @@ AddressClass ObjectFileXCOFF::GetAddressClass(addr_t
file_addr) {
return AddressClass::eUnknown;
}
-void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
+lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type sym_type) {
+ if (sym_type == ll
https://github.com/labath commented:
The code seems okay. I don't know anything about the format, so I don't know
which parts are "obvious" and which not, but I'd encourage you to add comments
where you think it might be useful.
You're right that lldb-test doesn't dump symbols. You should be a
@@ -188,7 +188,74 @@ AddressClass ObjectFileXCOFF::GetAddressClass(addr_t
file_addr) {
return AddressClass::eUnknown;
}
-void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
+lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type sym_type) {
+ if (sym_type == ll
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/138687
___
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/141422
___
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.
A straight-forward patch. I have one comment, but that's really a problem with
the previous PR, so it'd be better to handle that separately.
The interesting (and very tricky) question is what to do about this feature in
the long run, as it
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/141799
>From bbef9674f7e5cf9fbc488e27dfd0e35fed23608a Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Wed, 28 May 2025 18:25:46 +0200
Subject: [PATCH] [lldb] Refactor away UB in SBValue::GetLoadAddress
The problem wa
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/141799
The problem was in calling GetLoadAddress on a value in the error state, where
`ValueObject::GetLoadAddress` could end up accessing the uninitialized "address
type" by-ref return value from `GetAddressOf`. This
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/141738
___
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.
:+1:
https://github.com/llvm/llvm-project/pull/141774
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -19,8 +19,6 @@ def expect_var_path(self, expr, compare_to_framevar=False,
value=None, type=None
self.runCmd("settings set target.experimental.use-DIL true")
self.assertEqual(value_dil.GetValue(), value_frv.GetValue())
-# int_arr[100] sometimes p
https://github.com/labath approved this pull request.
Looks good. Thanks for the fix.
https://github.com/llvm/llvm-project/pull/141478
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commit
labath wrote:
> @labath
>
> We need to handle situations where the core won't have a valid platform, and
> then fallback to other info (like PRSTATUS).
>
> Please check the last commit in this patch. I think this will almost
> exclusively be an artifact of our tests, but I'm not sure how else
labath wrote:
> > @petrhosek Hey Petr, can you provide more information? For Linux
> > environments, SI_DETHREAD should be present. The commit for this signal
> > specifically is 13 years old, @DavidSpickett do you have any insight as to
> > why this is happening?
> > [SI_DETHREAD](https://git
@@ -2393,62 +2321,53 @@ lldb::addr_t SBTarget::GetStackRedZoneSize() {
bool SBTarget::IsLoaded(const SBModule &module) const {
LLDB_INSTRUMENT_VA(this, module);
- TargetSP target_sp(GetSP());
- if (!target_sp)
-return false;
-
- ModuleSP module_sp(module.GetSP());
-
@@ -1926,20 +1863,21 @@ SBValueList SBTarget::FindGlobalVariables(const char
*name,
SBValueList sb_value_list;
- TargetSP target_sp(GetSP());
- if (name && target_sp) {
-VariableList variable_list;
-target_sp->GetImages().FindGlobalVariables(ConstString(name), ma
@@ -1593,11 +1545,12 @@ SBModule SBTarget::FindModule(const SBFileSpec
&sb_file_spec) {
LLDB_INSTRUMENT_VA(this, sb_file_spec);
SBModule sb_module;
- TargetSP target_sp(GetSP());
- if (target_sp && sb_file_spec.IsValid()) {
-ModuleSpec module_spec(*sb_file_spec);
-
@@ -1841,31 +1776,33 @@ lldb::SBSymbolContextList
SBTarget::FindGlobalFunctions(const char *name,
lldb::SBType SBTarget::FindFirstType(const char *typename_cstr) {
LLDB_INSTRUMENT_VA(this, typename_cstr);
- TargetSP target_sp(GetSP());
- if (typename_cstr && typename_cstr
@@ -1355,29 +1312,30 @@ SBTarget::WatchpointCreateByAddress(lldb::addr_t addr,
size_t size,
SBWatchpoint sb_watchpoint;
lldb::WatchpointSP watchpoint_sp;
- TargetSP target_sp(GetSP());
- uint32_t watch_type = 0;
- if (options.GetWatchpointTypeRead())
-watch_type |=
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/141284
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1954,41 +1892,42 @@ SBValueList SBTarget::FindGlobalVariables(const char
*name,
SBValueList sb_value_list;
- TargetSP target_sp(GetSP());
- if (name && target_sp) {
-llvm::StringRef name_ref(name);
-VariableList variable_list;
+ if (TargetSP target_sp = GetS
@@ -1887,34 +1823,35 @@ lldb::SBTypeList SBTarget::FindTypes(const char
*typename_cstr) {
LLDB_INSTRUMENT_VA(this, typename_cstr);
SBTypeList sb_type_list;
- TargetSP target_sp(GetSP());
- if (typename_cstr && typename_cstr[0] && target_sp) {
-ModuleList &images = t
@@ -1606,66 +1559,60 @@ SBSymbolContextList SBTarget::FindCompileUnits(const
SBFileSpec &sb_file_spec) {
LLDB_INSTRUMENT_VA(this, sb_file_spec);
SBSymbolContextList sb_sc_list;
- const TargetSP target_sp(GetSP());
- if (target_sp && sb_file_spec.IsValid())
-target_s
@@ -1113,10 +1082,11 @@ SBBreakpoint SBTarget::FindBreakpointByID(break_id_t
bp_id) {
LLDB_INSTRUMENT_VA(this, bp_id);
SBBreakpoint sb_breakpoint;
- TargetSP target_sp(GetSP());
- if (target_sp && bp_id != LLDB_INVALID_BREAK_ID) {
-std::lock_guard guard(target_sp->G
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/141062
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
> Added some delay
You did, but to the wrong place. What I'm trying to ensure is that the child
process does not exit before we can observe it. This makes that failure mode
even likelier.
Take a look at the suggested edits to see what I had in mind.
https
@@ -90,6 +92,30 @@ TEST(Host, LaunchProcessSetsArgv0) {
ASSERT_THAT(exit_status.get_future().get(), 0);
}
+TEST(Host, FindProcesses) {
+ SubsystemRAII subsystems;
+
+ if (test_arg != 0)
+exit(0);
+
+ ProcessLaunchInfo info;
+ ProcessInstanceInfoList processes;
+ Pro
@@ -723,22 +703,23 @@ SBBreakpoint SBTarget::BreakpointCreateByLocation(
LLDB_INSTRUMENT_VA(this, sb_file_spec, line, column, offset, sb_module_list);
SBBreakpoint sb_bp;
- TargetSP target_sp(GetSP());
- if (target_sp && line != 0) {
-std::lock_guard guard(target_sp-
@@ -90,6 +92,30 @@ TEST(Host, LaunchProcessSetsArgv0) {
ASSERT_THAT(exit_status.get_future().get(), 0);
}
+TEST(Host, FindProcesses) {
+ SubsystemRAII subsystems;
+
+ if (test_arg != 0)
+exit(0);
labath wrote:
```suggestion
if (test_arg != 0) {
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/141610
___
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.
Okay, looks good then. Thanks for your patience.
https://github.com/llvm/llvm-project/pull/140150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -90,6 +92,30 @@ TEST(Host, LaunchProcessSetsArgv0) {
ASSERT_THAT(exit_status.get_future().get(), 0);
}
+TEST(Host, FindProcesses) {
+ SubsystemRAII subsystems;
+
+ if (test_arg != 0)
+exit(0);
+
+ ProcessLaunchInfo info;
+ ProcessInstanceInfoList processes;
+ Pro
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/138687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
This PR also contains clang and compiler-rt changes. You'll have better luck
finding someone to approve your PR if you split it along subproject boundaries.
Also, what's up with the extra blank line after the first header you are adding
everywhere? I don't
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/141284
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
I'm not sure this change is beneficial in the cases where it causes an increase
in the level of indentation (due to separating the check for TargetSP from
other validity checks).
What would you say to using the c++17 init-statement, plus condition?
https:/
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/141217
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/141217
It's already called in llvm_add_library.
>From 1da42847de2c438ae726b9800843f6449fede41a Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Fri, 23 May 2025 11:22:40 +0200
Subject: [PATCH] [lldb/cmake] Don't call
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/141066
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -480,3 +481,111 @@ CompilerType PlatformLinux::GetSiginfoType(const
llvm::Triple &triple) {
ast->CompleteTagDeclarationDefinition(siginfo_type);
return siginfo_type;
}
+
+static std::string GetDescriptionFromSiginfo(lldb::ValueObjectSP siginfo_sp) {
+ if (!siginfo_sp)
@@ -480,3 +481,111 @@ CompilerType PlatformLinux::GetSiginfoType(const
llvm::Triple &triple) {
ast->CompleteTagDeclarationDefinition(siginfo_type);
return siginfo_type;
}
+
+static std::string GetDescriptionFromSiginfo(lldb::ValueObjectSP siginfo_sp) {
+ if (!siginfo_sp)
https://github.com/labath commented:
> One area that I couldn't decide is if the ValueObj should be constructed in
> Platform or not. Because Thread calls out to platform I just decided to call
> the existing method, but I wanted your feedback on this because it does feel
> somewhat split purp
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/140150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/141066
>From 498052aef6ae24353bb50771bac773908da51b5d Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 22 May 2025 15:50:01 +0200
Subject: [PATCH] [lldb/cmake] Remove special handling of OBJECT libraries
Nothing
@@ -0,0 +1,119 @@
+"""
+Test DIL array subscript.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from lldbsuite.test import lldbutil
+
+
+class TestFrameVarDILArraySubscript(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+
https://github.com/labath approved this pull request.
I think it's fine. the std::vector formatter tests are not running currently on
windows, so it's likely that formatter is just broken there. Since this is test
for the DIL and not std::vector, we could write our own formatter to test this
f
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/141102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> I don't know if this is the source of the problem, but one thing I noticed is
> that you're missing some sort of synchronization to make sure the child
> process doesn't exit before you're able to observe it. A slightly lame but
> probably sufficient method to do that would be
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/141063
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -11,7 +11,7 @@ image show-unwind -n func0
# CHECK-NEXT: This UnwindPlan is sourced from the compiler: yes.
# CHECK-NEXT: This UnwindPlan is valid at all instruction locations: no.
# CHECK-NEXT: This UnwindPlan is for a trap handler function: no.
-# CHECK-NEXT: Address range
@@ -100,29 +100,25 @@ function(add_lldb_library name)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
labath wrote:
Yes, kinda, although it's moot while it's unused. However, the idea was that if
someone explicitly asks for an OBJECT library, he should get
@@ -93,13 +93,6 @@ function(add_lldb_library name)
set(libkind STATIC)
endif()
- #PIC not needed on Win
- # FIXME: Setting CMAKE_CXX_FLAGS here is a no-op, use target_compile_options
labath wrote:
I believe we don't -- and I think that's the right thi
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/141066
Nothing in lldb sets this. And even if they did, llvm_add_library should know
how to handle that.
>From b2d4e92fcc647d36671c5de682e3af2d1978de0f Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 22 May 202
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/141063
Like the comment says, this really is a no-op and has no offect on the
generated build commants.
>From 5eac5e7976005c74d5e1d669a64596688b3d8d25 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 22 May 2025
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/141062
None
>From 298dcd8cc367050e7dcb6dd8644073305c72c6e7 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 22 May 2025 14:53:44 +0200
Subject: [PATCH] [lldb] Make AddressRange dump easier on the eye
---
lldb/s
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/140927
___
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/138093
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -88,6 +89,42 @@ class IdentifierNode : public ASTNode {
std::string m_name;
};
+class MemberOfNode : public ASTNode {
+public:
+ MemberOfNode(uint32_t location, ASTNodeUP base, bool is_arrow,
+ std::string name, lldb::DynamicValueType use_dynamic,
+
https://github.com/labath commented:
I think this is good strategy -- take the existing implementation of `.` and
improve that later.
I have one comment about the location of the members, but otherwise, I think
this looks good.
https://github.com/llvm/llvm-project/pull/138093
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/140228
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -10,8 +10,16 @@ add_lldb_unittest(DAPTests
VariablesTest.cpp
LINK_LIBS
+liblldb
lldbDAP
+lldbUtilityHelpers
LLVMTestingSupport
LINK_COMPONENTS
Support
)
+
+set(test_inputs
+ linux-x86_64.out
+ linux-x86_64.core
labath wrot
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/140993
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/140927
Basically, disable everything except the eh_frame unwind plan, as that's the
only one which supports this right now. The other plans are working with now
trying the interpret everything in between the function p
https://github.com/labath commented:
[I'm sorry, this is going to be long]
Most of David's comments are there because you copied the existing attach
implementation. Even if we go down the path of different attach methods, I
don't think it's necessary to copy all of that. Actual attaching is a
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/137041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -312,10 +312,27 @@ NativeProcessLinux::Manager::Attach(
Log *log = GetLog(POSIXLog::Process);
LLDB_LOG(log, "pid = {0:x}", pid);
- auto tids_or = NativeProcessLinux::Attach(pid);
- if (!tids_or)
-return tids_or.takeError();
- ArrayRef<::pid_t> tids = *tids_or;
+
labath wrote:
The failure is in lldb_private::HostInfoBase::GetArchitecture. To fix this, you
need to `Initialize()` the HostInfo class.
https://github.com/llvm/llvm-project/pull/138687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/
labath wrote:
> > Could you also make unit tests for these two functions:
> >
> > * call GetProgramFileSpec and make sure the result is reasonable (exists?)
> > * create a Process and make sure FindProcesses finds it (you can use
> > [this](https://github.com/llvm/llvm-project/blob/52f568dbbb61
@@ -54,6 +54,12 @@ TEST_F(HostInfoTest, GetHostname) {
EXPECT_TRUE(HostInfo::GetHostname(s));
}
+TEST_F(HostInfoTest, GetProgramFileSpec) {
+ // Test GetProgramFileSpec()
labath wrote:
That much is obvious.
```suggestion
```
https://github.com/llvm/llvm-
@@ -54,6 +54,12 @@ TEST_F(HostInfoTest, GetHostname) {
EXPECT_TRUE(HostInfo::GetHostname(s));
}
+TEST_F(HostInfoTest, GetProgramFileSpec) {
+ // Test GetProgramFileSpec()
+ FileSpec filespec = HostInfo::GetProgramFileSpec();
+ EXPECT_FALSE(filespec.GetFilename().IsEmpty()
@@ -90,6 +90,31 @@ TEST(Host, LaunchProcessSetsArgv0) {
ASSERT_THAT(exit_status.get_future().get(), 0);
}
+TEST(Host, FindProcesses) {
+ SubsystemRAII subsystems;
+
+ if (test_arg != 0)
+exit(0);
+
+ ProcessLaunchInfo info;
+ ProcessInstanceInfoList processes;
+ Pro
@@ -10,8 +10,16 @@ add_lldb_unittest(DAPTests
VariablesTest.cpp
LINK_LIBS
+liblldb
lldbDAP
+lldbUtilityHelpers
LLVMTestingSupport
LINK_COMPONENTS
Support
)
+
+set(test_inputs
+ linux-x86_64.out
+ linux-x86_64.core
labath wrot
labath wrote:
Correct.
https://github.com/llvm/llvm-project/pull/140150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
That would be great, thanks.
BTW, I've checked the test and its form after
https://github.com/llvm/llvm-project/pull/140331 (where `self.launch` does not
send the configurationDone` event) does reproduce the problem I encountered.
https://github.com/llvm/llvm-project/pull/138219
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
I'm glad we're in (abstract) agreement. As much as I would like to, I can't
promise to do this by any particular date. I'd can *try*, but I don't know when
will that happen.
In a way, I feel that this patch isn't the a good reason to motivate this
(although I think that legalisi
https://github.com/labath commented:
I think this is a pretty good attempt. Thanks for trying it out.
My main problem with it is that I still think that this functionality should be
in the platform class. I have a couple of reasons for that:
- the platform class is the one who defines the layou
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/139196
___
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/140256
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -272,4 +272,52 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/138551
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -272,4 +272,67 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected
+Interpreter::Visit(const ArraySubscriptNode *node) {
+ auto lhs_or_err = Evaluate(node->GetBase());
+ if (!lhs
labath wrote:
gmock doesn't let you do anything that wouldn't be possible without it. For
this to work, the code which interacts with the mock needs to be ready to
accept something other than the real object somehow. That usually means
making the mocked object polymorphic, but that is a no
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/139002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
FWIW, https://github.com/llvm/llvm-project/pull/140331 fixes this. I was
looking at the test coverage, and it seems that the only test making use of
this is TestDAP_setBreakpoints.py. It superficially looks like it should catch
this, but after trying it out, it seems that it does
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/140256
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
I think I've found a(nother) problem with this change. One of the arguments of
the launch request is `sourceMap`, which sets the `target.source-map` setting.
The setting is necessary to correctly resolve file+line breakpoints in case the
file's path on the host system does not ma
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/140228
This reapplies https://github.com/llvm/llvm-project/pull/138892, which was
reverted in
https://github.com/llvm/llvm-project/commit/5fb9dca14aeaf12219ff149bf3a4f94c8dc58d8b
due to failures on windows.
Windows lo
1 - 100 of 4384 matches
Mail list logo
