https://github.com/sayhaan created
https://github.com/llvm/llvm-project/pull/100851
Adds tests to check debug_ranges with an increased batch size and sets previous
test's batch size at 1 to prevent a functional change.
>From ace8031ce49898d2f59b32eb07f2208461da9028 Mon Sep 17 00:00:00 2001
Fro
https://github.com/xgupta edited https://github.com/llvm/llvm-project/pull/94844
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/xgupta closed https://github.com/llvm/llvm-project/pull/95675
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Shivam Gupta
Date: 2024-07-27T07:05:44+05:30
New Revision: 558315a0ea8cae8613c3a0061bc6cbe50c5b392f
URL:
https://github.com/llvm/llvm-project/commit/558315a0ea8cae8613c3a0061bc6cbe50c5b392f
DIFF:
https://github.com/llvm/llvm-project/commit/558315a0ea8cae8613c3a0061bc6cbe50c5b392f.diff
@@ -52,6 +52,7 @@ def test_negative_indexing(self):
self.build()
self.validate_negative_indexing()
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Seems like my Clang invocation is generating different debu
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Vladislav Dzhidzhoev (dzhidzhoev)
Changes
Use llvm-strip from llvm tools dir if no path to strip is set. Tests are
changed to use cmake-provided strip.
This is useful for Windows host-Linux remote testing.
---
Full diff: https://github.co
https://github.com/dzhidzhoev created
https://github.com/llvm/llvm-project/pull/100836
Use llvm-strip from llvm tools dir if no path to strip is set. Tests are
changed to use cmake-provided strip.
This is useful for Windows host-Linux remote testing.
>From 23eb3773023c669b6eee43a6242d86c1e706
@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
llvm-beanz wrot
slydiman wrote:
> One way I can imagine this happening is if the FileSystem instance was local
> to a GDBRemoteCommunicationServerPlatform instance -- rather than the thread
> it happens to be (mostly) running on. This will require more changes to,
> basically, plumb the filesystem instance to
@@ -8001,6 +8001,12 @@ NamedDecl *Sema::ActOnVariableDeclarator(
}
}
+ if (getLangOpts().HLSL) {
+if (R->isHLSLSpecificType() && !NewVD->isImplicit()) {
+ Diag(D.getBeginLoc(), diag::err_hlsl_intangible_type_cannot_be_declared);
hekota wrote:
https://github.com/slydiman edited
https://github.com/llvm/llvm-project/pull/100670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/slydiman edited
https://github.com/llvm/llvm-project/pull/100670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/slydiman edited
https://github.com/llvm/llvm-project/pull/100670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -52,6 +52,7 @@ def test_negative_indexing(self):
self.build()
self.validate_negative_indexing()
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
If I change this line:
```
self.runCmd("expr -i 0 -- call_
@@ -52,6 +52,7 @@ def test_negative_indexing(self):
self.build()
self.validate_negative_indexing()
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Here's the full output with 3e06392 cherry-picked. https://
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
kendalharland wrote:
I've removed CMAKE_CXX_STANDARD=14 above as it is leftover from debugging and
not correct or necessary.
https://github.com/llvm/llvm-project/pull/100476
__
kendalharland wrote:
> > ```
> > S:\SourceCache\llvm-project\lldb\test\Shell\Driver\TestConvenienceVariables.test:6:8:
> > error: CHECK: expected string not found in input
> > CHECK: stop reason = breakpoint 1.1
> >^
> > :1:1: note: scanning from here
> > (lldb) command source -s 0
> >
https://github.com/kendalharland closed
https://github.com/llvm/llvm-project/pull/100473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
kendalharland wrote:
For reference, my current setup steps are the following commands run in a
non-admin cmd.exe
```
C:\Program Files\Microsoft Visual
Studio\2022\Community\Common7\Tools\VsDevCmd.bat
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100476
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
kendalharland wrote:
@DavidSpickett would you be able to share the CMake configuration your native
Windows native CI is using? I'm having trouble spotting what's wrong with my
local build.
https://g
@@ -6608,8 +6610,9 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
mach_header.ncmds = segment_load_commands.size();
mach_header.flags = 0;
mach_header.reserved = 0;
-ThreadList &thread_list = process_sp->GetThreadList();
-
@@ -26,3 +26,14 @@ def test_default_corestyle_behavior(self):
"""Test that the default core style is unspecified."""
options = lldb.SBSaveCoreOptions()
self.assertEqual(options.GetStyle(), lldb.eSaveCoreUnspecified)
+
+def test_adding_and_removing_th
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if
@@ -46,8 +46,59 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+void SaveCoreOptions::AddThread(lldb::tid_t tid) {
+ if (m_threads_to_save.count(tid) == 0)
+m_threads_to_save.emplace(tid);
+}
+
+bool SaveCoreOptions::RemoveThread(lldb::tid_t tid) {
+ if (
@@ -6621,29 +6624,28 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
LC_THREAD_data.SetAddressByteSize(addr_byte_size);
LC_THREAD_data.SetByteOrder(byte_order);
}
-for (uint32_t thread_idx = 0; thread_idx < num_threads;
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if
@@ -53,6 +54,27 @@ class LLDB_API SBSaveCoreOptions {
/// \return The output file spec.
SBFileSpec GetOutputFile() const;
+ /// Set the process to save, or unset if supplied with a null process.
clayborg wrote:
change `null process` to a `default constru
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
+return error;
+ }
+
+ if
@@ -6729,8 +6731,7 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
std::make_shared());
StructuredData::ArraySP threads(
std::make_shared());
-for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
-
@@ -6668,6 +6676,18 @@ Status
Process::CalculateCoreFileSaveRanges(lldb::SaveCoreStyle core_style,
return Status(); // Success!
}
+std::vector
+Process::CalculateCoreFileThreadList(const SaveCoreOptions &core_options) {
+ std::vector thread_list;
+ for (const auto &thread
@@ -53,6 +54,27 @@ class LLDB_API SBSaveCoreOptions {
/// \return The output file spec.
SBFileSpec GetOutputFile() const;
+ /// Set the process to save, or unset if supplied with a null process.
+ ///
+ /// \param process The process to save.
+ /// \return Success if p
@@ -46,8 +48,79 @@ SaveCoreOptions::GetOutputFile() const {
return m_file;
}
+Status SaveCoreOptions::SetProcess(lldb::ProcessSP process_sp) {
+ Status error;
+ if (!process_sp) {
+ClearProcessSpecificData();
+m_process_sp = nullptr;
clayborg wrote
@@ -6621,29 +6624,28 @@ bool ObjectFileMachO::SaveCore(const lldb::ProcessSP
&process_sp,
LC_THREAD_data.SetAddressByteSize(addr_byte_size);
LC_THREAD_data.SetByteOrder(byte_order);
}
-for (uint32_t thread_idx = 0; thread_idx < num_threads;
@@ -12,6 +12,7 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Ty! I'll try that out.
https://github.com/llvm/llvm-project/pull/100477
__
@@ -52,6 +52,7 @@ def test_negative_indexing(self):
self.build()
self.validate_negative_indexing()
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
kendalharland wrote:
Thanks! I'll try that and update here.
https://github.com/
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100487
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100487
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kendalharland wrote:
> The only way that this could succeed on the breakpoint but fail on the
> location is that there is more than one location and the one the test is
> setting it on (the zeroth) is not the one that's hit. Since this test is
> "does a breakpoint condition on a location work"
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/100487
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland updated
https://github.com/llvm/llvm-project/pull/100487
>From 29d5a57eb8cc344e1a93787fe9cb333761923927 Mon Sep 17 00:00:00 2001
From: kendal
Date: Tue, 23 Jul 2024 10:24:24 -0700
Subject: [PATCH] [lldb][test][x86_64][win] Split TestBreakpointConditions
asserti
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Kendal Harland
Date: 2024-07-26T10:43:58-07:00
New Revision: 3e593b9b3b86ebf28e24c3a33791be49e0735af5
URL:
https://github.com/llvm/llvm-project/commit/3e593b9b3b86ebf28e24c3a33791be49e0735af5
DIFF:
https://github.com/llvm/llvm-project/commit/3e593b9b3b86ebf28e24c3a33791be49e0735af5.diff
https://github.com/dzhidzhoev edited
https://github.com/llvm/llvm-project/pull/99266
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/dzhidzhoev edited
https://github.com/llvm/llvm-project/pull/99266
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/dzhidzhoev edited
https://github.com/llvm/llvm-project/pull/99266
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
endif
CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem
$(SDKROOT)/usr/include/c++/v1
LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++
+else
+ifneq (,$(findstring clang,$
kendalharland wrote:
Thanks for the reviews! I'll need help merging from someone with write access
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
https://github.com/kendalharland updated
https://github.com/llvm/llvm-project/pull/100660
>From 6769752234f67ac693ea7345393fd9d72fa4a567 Mon Sep 17 00:00:00 2001
From: kendal
Date: Thu, 25 Jul 2024 14:59:25 -0700
Subject: [PATCH] [lldb][test] Remove getCompilerBinary() helper
---
.../packages
kendalharland wrote:
> Seems fine to me, but there is a use of it in
> `lldb/packages/Python/lldbsuite/test/lldbtest.py` that should also be removed.
Not sure how I missed that one. Ty!
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commit
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/99266
>From 4e8dec03681b223fa7eec05c8a5a49ef11165b18 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Mon, 15 Jul 2024 22:52:40 +0200
Subject: [PATCH] [LLDB][test] Update Makefile.rules to support Windows
@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
*m_dwo_id, m_first_die.GetOffset()));
return; // Can't fetch the compile unit from the dwo file.
}
- // If the skeleton compile unit gets its unit DIE parsed first, then this
- // will fill in the DW
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/100577
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
All changes look good as is, just one inline question about maybe not setting
the error if we detect the .dwo files are both empty (if it is possible to do).
https://github.com/llvm/llvm-project/pull/100577
___
l
@@ -718,13 +720,11 @@ DWARFCompileUnit *DWARFUnit::GetSkeletonUnit() {
return llvm::dyn_cast_or_null(m_skeleton_unit);
}
-void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit) {
- // If someone is re-setting the skeleton compile unit backlink, make sure
- // it is sett
@@ -170,7 +170,7 @@ class DWARFUnit : public UserID {
/// both cases correctly and avoids crashes.
DWARFCompileUnit *GetSkeletonUnit();
- void SetSkeletonUnit(DWARFUnit *skeleton_unit);
+ bool LinkToSkeletonUnit(DWARFUnit &skeleton_unit);
clayborg wrote:
https://github.com/bulbazord approved this pull request.
https://github.com/llvm/llvm-project/pull/95675
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
My main questions is do we actually use wildcards a lot? In normal type query
matches, we can ask for exact matches where everything is specified, or the
user types some string like `a::b::iterator` where we don't know what any of
the items are. If exact
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/100660
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/100710
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/100710
>From 59f8a161ec1ccb4c5b13c6760f652f574a4b435d Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 26 Jul 2024 01:58:54 +0100
Subject: [PATCH 1/2] [lldb][TypeSystemClang] Don't create VLAs of explicitly
0
https://github.com/tedwoodward edited
https://github.com/llvm/llvm-project/pull/99336
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/100674
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-07-26T16:47:47+01:00
New Revision: 11a7ee50b400fc13cf772c81e09c153c93665658
URL:
https://github.com/llvm/llvm-project/commit/11a7ee50b400fc13cf772c81e09c153c93665658
DIFF:
https://github.com/llvm/llvm-project/commit/11a7ee50b400fc13cf772c81e09c153c93665658.diff
Michael137 wrote:
Test failure is:
```
2024-07-26 07:38:47 BST Timed Out Tests (1):
2024-07-26 07:38:47 BST lldb-api ::
functionalities/fork/concurrent_vfork/TestConcurrentVFork.py
```
Which is unrelated (and I've seen be flakey lately). Will merge now
https://github.com/llvm/llvm-project/pu
https://github.com/tedwoodward closed
https://github.com/llvm/llvm-project/pull/99926
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Santhosh Kumar Ellendula
Date: 2024-07-26T10:22:33-05:00
New Revision: 73450251497f3880ff90d36d2bb43f02dd022239
URL:
https://github.com/llvm/llvm-project/commit/73450251497f3880ff90d36d2bb43f02dd022239
DIFF:
https://github.com/llvm/llvm-project/commit/73450251497f3880ff90d36d2bb43f02dd0
slydiman wrote:
Of course lldb waits for the vFile:close response before sending the vRun
packet and lldb-server actually closes the file handle (all of them). No any
leaks. Otherwise this workaround wouldn't work.
The behavior is the same on Linux and Windows targets. I launched 100
connect
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/100674
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -4725,67 +4725,69 @@ TypeSystemClang::GetFloatTypeSemantics(size_t
byte_size) {
return llvm::APFloatBase::Bogus();
}
+std::optional
+TypeSystemClang::GetObjCBitSize(QualType qual_type,
+ExecutionContextScope *exe_scope) {
+ assert(qual_ty
DavidSpickett wrote:
> When you display registers bitfields do you have a ValueObject?
Yes:
https://github.com/llvm/llvm-project/blob/6808e6c78edf63d2c0c9bd6fce168fe7e0a7d49f/lldb/source/Core/DumpRegisterValue.cpp#L47
I'm just calling `dump`, there's no register specific code there, ideally I
https://github.com/slydiman closed
https://github.com/llvm/llvm-project/pull/100666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Dmitry Vasilyev
Date: 2024-07-26T19:12:05+04:00
New Revision: f083764ba1ca35016c929683c8a5d918b5048100
URL:
https://github.com/llvm/llvm-project/commit/f083764ba1ca35016c929683c8a5d918b5048100
DIFF:
https://github.com/llvm/llvm-project/commit/f083764ba1ca35016c929683c8a5d918b5048100.dif
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/100666
>From 0e451f16b91bab2bc2cd1375eb02e4fe71998790 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Fri, 26 Jul 2024 02:40:49 +0400
Subject: [PATCH 1/3] [lldb] Optimized lldb-server memory usage
MAX_PATH is de
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
bytes_read += result;
if (bytes_read == size || result == 0)
break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() h
slydiman wrote:
> to replace the fork with spawning a new process (fork+execve) instead. Have
> you considered that?
To fix all gdb port mapping issues we need a common port mapping available to
all platform connections. It is possible only with the multithreading.
https://github.com/llvm/llv
https://github.com/labath approved this pull request.
I suggest Monday. If anything breaks, at least there'll be someone around to do
something about it.
https://github.com/llvm/llvm-project/pull/99589
___
lldb-commits mailing list
lldb-commits@lists.
dzhidzhoev wrote:
> Libc++ supports a [large
> number](https://github.com/llvm/llvm-project/blob/6235698f47828747d3b1b0418e547e2e4ff9138f/libcxx/cmake/Modules/HandleLibCXXABI.cmake#L85)
> of configurations when in comes to the ABI library.
>
> I think the most common are: shared-libcxx+shared-
@@ -12,6 +12,7 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
dzhidzhoev wrote:
Also, it may be worth cherry-picking this
https://github.com/llvm/llvm-project/commit
@@ -12,6 +12,7 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])
dzhidzhoev wrote:
Could you provide a failure log for this? It passes on our CI (Windows native
x86_64)
Author: Vladislav Dzhidzhoev
Date: 2024-07-26T14:28:11+02:00
New Revision: 6a1a393997fb5f7bdb01943ed48dc72d48861824
URL:
https://github.com/llvm/llvm-project/commit/6a1a393997fb5f7bdb01943ed48dc72d48861824
DIFF:
https://github.com/llvm/llvm-project/commit/6a1a393997fb5f7bdb01943ed48dc72d4886182
https://github.com/dzhidzhoev closed
https://github.com/llvm/llvm-project/pull/100628
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
# Make sure lldb can handle filenames with single quotes in them.
# RUN: %clang_host %p/Inputs/hello.c -g -o "%t-'pat"
dzhidzhoev wrote:
The same as for TestConvenienceVariables.test:
```
PASS: lldb-
@@ -1,3 +1,5 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
We have it green as well
```
PASS: lldb-shell :: SymbolFile/DWARF/x86/dead-code-filtering.yaml (389 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at lin
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
```
PASS: lldb-shell :: Settings/TestEchoCommands.test (315 of 543)
Exit Code: 0
Command Output (stdout):
--
# RUN: at line 1
c:\build-lldb-native\bin\lldb.exe --
@@ -1,5 +1,7 @@
// clang-format off
+// XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
As far as I understand, NativePDB tests only run for Windows host+Windows
target, contrary to the tests from the PDB folder which we managed to run on
Linux t
@@ -1,3 +1,4 @@
+# XFAIL: target=x86_64-{{.*}}-windows{{.*}}
dzhidzhoev wrote:
Interestingly, this test is green on our Windows native CI. It uses cmd.exe.
Here's the log:
```
PASS: lldb-shell :: Driver/TestConvenienceVariables.test (88 of
rocallahan wrote:
> The two are different when it comes to the ABI
Yeah OK. I've fixed that.
https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
https://github.com/rocallahan updated
https://github.com/llvm/llvm-project/pull/99736
>From e9a44b4cfd2e3423fbf5ac75124530cc2bb8afed Mon Sep 17 00:00:00 2001
From: Robert O'Callahan
Date: Fri, 19 Jul 2024 22:46:42 +1200
Subject: [PATCH] [lldb] Implement basic support for reverse-continue
This
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/99305
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
bool TypeQuery::ContextMatches(
llvm::ArrayRef context_chain) const {
- if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
-
labath wrote:
> One thing that's not entirely clear to me from the discussion so far:
> apparently the public API rules allow adding an overload of
> `SBProcess::Continue()` with a direction parameter. Do they allow just adding
> a direction parameter to the existing overload _with a default v
@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
bool TypeQuery::ContextMatches(
llvm::ArrayRef context_chain) const {
- if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
-
rocallahan wrote:
One thing that's not entirely clear to me from the discussion so far:
apparently the public API rules allow adding an overload of
`SBProcess::Continue()` with a direction parameter. Do they allow just adding a
direction parameter to the existing overload *with a default value
labath wrote:
One way I can imagine this happening is if the FileSystem instance was local to
a `GDBRemoteCommunicationServerPlatform` instance -- rather than the thread it
happens to be (mostly) running on. This will require more changes to,
basically, plumb the filesystem instance to every p
https://github.com/labath commented:
This looks much better, and it looks like @dzhidzhoev is just about to remove
some of the same XFAILS as well (in #100628). I suggest you two collaborate on
the remaining ones.
https://github.com/llvm/llvm-project/pull/100477
___
1 - 100 of 127 matches
Mail list logo
