@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/141983
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/141981
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
I agree with Pavel that using `-` for ranges of bitfields was an unfortunate
choice, which really only worked because we didn't intend to provide the
addition operators in the ValueObject path specifications. Now that we're
going to add those, we ought to switch to something
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/141529
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jyknight wrote:
I'm trying to update some non-in-tree code after this change, and I don't think
I understand the newly-expected lifetime rules after this change. I see all the
comments that say this makes lifetime clearer...so I expect I'm just
misunderstanding things.
Previously, Diagnostics
Jlalond wrote:
I'm going to wait to see how many build issues we get before landing.
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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
@@ -34,6 +34,20 @@
#define MAP_PRIVATE 2
#define MAP_ANON 0x20
+// For other platforms that use platform linux
+#ifndef SIGILL
+#define SIGILL 4
+#endif
+#ifndef SIGBUS
+#define SIGBUS 7
+#endif
+#ifndef SIGFPE
+#define SIGFPE 8
+#endif
+#ifndef SIGSEGV
+#define SIGSEGV 11
---
Jlalond wrote:
Hey @felipepiovezan am I reading green dragon right
https://green.lab.llvm.org/job/llvm.org/job/as-lldb-cmake/changes
Looks like the build with my changes failed (with I believe unrelated test
failures), then went green? Does that mean we're working on Darwin?
https://github.c
dlav-sc wrote:
@DavidSpickett, @asb could you take another look at this patch, please?
I've added support for instructional step for any possible riscv atomic
sequence (or at least I believe so). Additionally, I've made some minor
refactoring to the software's single-step logic.
https://githu
https://github.com/eronnen created
https://github.com/llvm/llvm-project/pull/142017
Fix TypeSCript comparison (when defining an empty config string like
`commandEscapePrefix=""` it would skip it)
>From 8632a15c5fa4a11b1a108d9b763b9241b5a2bc41 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Th
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ely Ronnen (eronnen)
Changes
Fix TypeSCript comparison (when defining an empty config string like
`commandEscapePrefix=""` it would skip it)
---
Full diff: https://github.com/llvm/llvm-project/pull/142017.diff
1 Files Affected:
- (modif
Jlalond wrote:
Put up a fix for Windows on #141971
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
https://github.com/dlav-sc edited
https://github.com/llvm/llvm-project/pull/127505
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DhruvSrivastavaX wrote:
@labath
> 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.
Sure, I have added some comments for that now.
> You're right
https://github.com/da-viper updated
https://github.com/llvm/llvm-project/pull/141122
>From 9408d17b1acf308c7a299bdc6c413a3505d1a039 Mon Sep 17 00:00:00 2001
From: Ebuka Ezike
Date: Wed, 21 May 2025 23:26:14 +0100
Subject: [PATCH 1/9] [lldb][lldb-dap] support DataBreakpointBytes capability
---
https://github.com/dmpots approved this pull request.
Approving to unblock windows build break.
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
@@ -34,6 +34,20 @@
#define MAP_PRIVATE 2
#define MAP_ANON 0x20
+// For other platforms that use platform linux
dmpots wrote:
Are these guaranteed to be defines and not constants?
https://github.com/llvm/llvm-project/pull/141971
_
@@ -34,6 +34,20 @@
#define MAP_PRIVATE 2
#define MAP_ANON 0x20
+// For other platforms that use platform linux
+#ifndef SIGILL
+#define SIGILL 4
+#endif
+#ifndef SIGBUS
+#define SIGBUS 7
+#endif
+#ifndef SIGFPE
+#define SIGFPE 8
+#endif
+#ifndef SIGSEGV
+#define SIGSEGV 11
---
https://github.com/dmpots edited
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ashgti wrote:
Looks like my tests failed on the buildkit linux host, looking into why
python3.10 failed. They passed on the 'CI Checks / Build and Test Linux' but
that has python 3.12.
https://github.com/llvm/llvm-project/pull/141689
___
lldb-commits
Author: Jacob Lalonde
Date: 2025-05-29T08:43:55-07:00
New Revision: 5fe9aea6d128a8569e27f8c66272e481f10c61ae
URL:
https://github.com/llvm/llvm-project/commit/5fe9aea6d128a8569e27f8c66272e481f10c61ae
DIFF:
https://github.com/llvm/llvm-project/commit/5fe9aea6d128a8569e27f8c66272e481f10c61ae.diff
Jlalond wrote:
@JDevlieghere I did run this on my local Mac (Very slowly on an M1 🥲). Got no
failures, but still FYI
https://github.com/llvm/llvm-project/pull/141670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
https://github.com/DavidSpickett commented:
I'm a bit bothered by how many `continue` are here, but they seem to be here
for good reasons.
Once you've addressed this round of comments I'll read it again and see if it's
clearer to me.
https://github.com/llvm/llvm-project/pull/141577
__
@@ -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/DavidSpickett 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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) {
Davi
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-win`
running on `as-builder-10` while building `lldb` at step 8 "build-default".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/197/builds/5997
Here is the relevant piece of the bui
https://github.com/Jlalond closed
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
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
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:
> 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
@@ -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/Jlalond closed
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Jlalond wrote:
@labath I'm landing to not leave the build broken, but if you have a better
solution/means of doing this let me know and I'll implement it
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists
Author: Jacob Lalonde
Date: 2025-05-29T11:20:05-07:00
New Revision: 159646cd39eb6451c8906a65e04d2566882f
URL:
https://github.com/llvm/llvm-project/commit/159646cd39eb6451c8906a65e04d2566882f
DIFF:
https://github.com/llvm/llvm-project/commit/159646cd39eb6451c8906a65e04d2566882f.diff
cmtice wrote:
> I agree with Pavel that using `-` for ranges of bitfields was an unfortunate
> choice, which really only worked because we didn't intend to provide the
> addition operators in the ValueObject path specifications. Now that we're
> going to add those, we ought to switch to someth
https://github.com/eronnen updated
https://github.com/llvm/llvm-project/pull/141426
>From 4c20703077eb4bbee8cfeb59022dec89d8697d83 Mon Sep 17 00:00:00 2001
From: Ely Ronnen
Date: Wed, 21 May 2025 23:39:56 +0200
Subject: [PATCH 1/4] Reuse creation of Source objects for assembly and normal
sourc
Jlalond wrote:
https://lab.llvm.org/buildbot/#/builders/197/builds/6014 looks like we're
passing
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/141995
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/141577
>From a62cd7b510f3cf74ee356a95a26e0f9922f4b39c Mon Sep 17 00:00:00 2001
From: DhruvSrivastavaX
Date: Tue, 27 May 2025 05:44:55 -0500
Subject: [PATCH 1/3] Added XCOFF ParseSymtab handling
---
.../Objec
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/141689
>From ad0a9cd321d260cd87b852b335da9565f8326449 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Tue, 27 May 2025 16:40:10 -0700
Subject: [PATCH 1/4] [lldb-dap] Test Gardening, improving DebugCommunication.
Imp
@@ -16,12 +15,61 @@
namespace lldb_dap {
+static llvm::Expected
+HandleDataBreakpointBytes(DAP &dap,
+ const protocol::DataBreakpointInfoArguments &args) {
+ llvm::StringRef address = args.name;
+
+ unsigned long long load_addr = LLDB_INVALID_ADDRES
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-x86_64-debian`
running on `lldb-x86_64-debian` while building `lldb` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/162/builds/23448
Here is the relevant piece of the build log
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/141670
>From 048cc769d6380bcb899bbcc5acf7f9349b51c5d3 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 27 May 2025 13:40:40 -0700
Subject: [PATCH 1/6] Reapply "[LLDB][ELF Core] Support all the Generic
(Negative
@@ -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
+
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/141971
Another iteration of fixes for #141670. Platform linux can be used by other
platforms, so we need to supply the signal values if they're not defined.
>From 0612b888a0dd0cda09fbaa89f5e68c15a1bc9e98 Mon Sep 17 00
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
Another iteration of fixes for #141670. Platform linux can be used by
other platforms, so we need to supply the signal values if they're not defined.
---
Full diff: https://github.com/llvm/llvm-project/pull/
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/141971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/141995
In #129307, we introduced read write in chunks, and during the final revision
of the PR I changed the behavior for 64b memory regions and did not test an
actual 64b memory range.
This caused LLDB to crash when
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
In #129307, we introduced read write in chunks, and during the final
revision of the PR I changed the behavior for 64b memory regions and did not
test an actual 64b memory range.
This caused LLDB to crash w
Jlalond wrote:
```
MINIDUMP_MEMORY64_LIST:
NumberOfMemoryRanges = 0x0042
BaseRva = 0x7f1963c0
MemoryRanges[0] = [0x - 0x7f1a4020)
MemoryRanges[1] = [0x - 0x7f1e0820)
MemoryRanges[2] = [0x00
https://github.com/dlav-sc updated
https://github.com/llvm/llvm-project/pull/127505
>From 2520b8d7884d320ed7923685b1a3e8652a7e8f5f Mon Sep 17 00:00:00 2001
From: Daniil Avdeev
Date: Fri, 23 May 2025 13:27:46 +
Subject: [PATCH 1/2] [lldb][RISCV] handle lr/sc single step
lldb-server had limi
https://github.com/ashgti closed
https://github.com/llvm/llvm-project/pull/141689
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham approved this pull request.
That worked out pretty well.
https://github.com/llvm/llvm-project/pull/141799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commit
Jlalond 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.
Are these actually different on Mac? These 4 are the same on BSD to my
knowledge.
How do you think we should go ab
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/141981
Trimming unused imports, adjusting the test to use the `DEFAULT_TIMEOUT`
instead of a custom timeout and adjusting the flow to stopOnEntry for improving
consistency.
>From 509b0a5643620b10e77216c7cde591b7e8ccb1
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
Trimming unused imports, adjusting the test to use the `DEFAULT_TIMEOUT`
instead of a custom timeout and adjusting the flow to stopOnEntry for improving
consistency.
---
Full diff: https://github.com/llvm/ll
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r HEAD~1...HEAD
lldb/test/API/riscv/step/TestSoftwareStep.py
``
View the diff f
ashgti wrote:
Okay, the latest version of this worked on buildkit for linux.
I'll submit this, but if we get reports of it failing with other specific
versions of python we may need to tweak things a bit.
https://github.com/llvm/llvm-project/pull/141689
___
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
Enabling the breakpoint tests, these have been stable for me locally and I
think with the recent changes this should be stable again in the CI.
---
Full diff: https://github.com/llvm/llvm-project/pull/141983.
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/141983
Enabling the breakpoint tests, these have been stable for me locally and I
think with the recent changes this should be stable again in the CI.
>From 60ca2ac18ccff832d2137107d3f5161614c02dd1 Mon Sep 17 00:00:00
https://github.com/dlav-sc updated
https://github.com/llvm/llvm-project/pull/127505
>From 2520b8d7884d320ed7923685b1a3e8652a7e8f5f Mon Sep 17 00:00:00 2001
From: Daniil Avdeev
Date: Fri, 23 May 2025 13:27:46 +
Subject: [PATCH 1/2] [lldb][RISCV] handle lr/sc single step
lldb-server had limi
Author: John Harrison
Date: 2025-05-29T09:51:27-07:00
New Revision: 8a49db35f45e56c92522c6079e51553e80c07aec
URL:
https://github.com/llvm/llvm-project/commit/8a49db35f45e56c92522c6079e51553e80c07aec
DIFF:
https://github.com/llvm/llvm-project/commit/8a49db35f45e56c92522c6079e51553e80c07aec.diff
ashgti wrote:
Looking into the failure on the buildbot.
https://github.com/llvm/llvm-project/pull/141689
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu`
running on `linaro-lldb-aarch64-ubuntu` while building `lldb` at step 6 "test".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/59/builds/18540
Here is the relevant piece of the b
ashgti wrote:
I'm surprised by some of these failures, since it passed on buildkite and the
premerge check that are also on linux x86_64. Trying to understand the reason
for these failures.
https://github.com/llvm/llvm-project/pull/141689
___
lldb-co
Author: Jacob Lalonde
Date: 2025-05-29T11:06:56-07:00
New Revision: 9ca41b6b65680c9eceb938c0e27d8d054114e680
URL:
https://github.com/llvm/llvm-project/commit/9ca41b6b65680c9eceb938c0e27d8d054114e680
DIFF:
https://github.com/llvm/llvm-project/commit/9ca41b6b65680c9eceb938c0e27d8d054114e680.diff
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/141995
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -58,6 +59,9 @@ class LLDB_API SBAddress {
// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)".
lldb::SBSymbolContext GetSymbolContext(uint32_t resolve_scope);
+ lldb::SBSymbolContext GetSymbolContext(const SBTarget &target,
+
@@ -45,9 +45,14 @@ def test_optimized_variable(self):
self.continue_to_breakpoints(breakpoint_ids)
optimized_variable = self.dap_server.get_local_variable("argc")
-self.assertTrue(optimized_variable["value"].startswith("https://github.com/llvm/llvm-proj
https://github.com/ashgti approved this pull request.
https://github.com/llvm/llvm-project/pull/142017
___
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/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
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/Nerixyz updated
https://github.com/llvm/llvm-project/pull/141529
>From 2a79486c4d45a8b4251ad32cd0629473c4ce828d Mon Sep 17 00:00:00 2001
From: Nerixyz
Date: Mon, 26 May 2025 22:25:05 +0200
Subject: [PATCH] [lldb-dap] Treat empty thread names as unset
---
lldb/test/API/tools
Nerixyz wrote:
> The launch sequence is in parallel. Is it possible that the two debug adapter
> implements are handling them in different orders? It took me a while to
> realize this. I found this diagram enlightening: [microsoft/vscode#4902
> (comment)](https://github.com/microsoft/vscode/is
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r HEAD~1...HEAD
lldb/test/API/tools/lldb-dap/threads/TestDAP_threads.py
``
View
https://github.com/Nerixyz updated
https://github.com/llvm/llvm-project/pull/141529
>From 2f597d5b2355d7b786d76457ca3435f6cd577e3e Mon Sep 17 00:00:00 2001
From: Nerixyz
Date: Mon, 26 May 2025 22:25:05 +0200
Subject: [PATCH] [lldb-dap] Treat empty thread names as unset
---
lldb/test/API/tools
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-ubuntu`
running on `as-builder-9` while building `lldb` at step 16
"test-check-lldb-api".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/195/builds/9716
Here is the relevant piece
@@ -0,0 +1,70 @@
+#!/usr/bin/env python3
DavidSpickett wrote:
Does this need a license header?
https://github.com/llvm/llvm-project/pull/138028
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.ll
DavidSpickett wrote:
@laverdet I've been told we need kernel changes to handle parts of this. Those
are planned, and I will work on the lldb side once they are available.
In the meantime, this patch does prevent lldb crashing but I'm not comfortable
merging it when other features won't work. I
https://github.com/Nerixyz updated
https://github.com/llvm/llvm-project/pull/141529
>From 0f5a95ebe67f54ba7dfe55ff8450226ba84f113d Mon Sep 17 00:00:00 2001
From: Nerixyz
Date: Mon, 26 May 2025 22:25:05 +0200
Subject: [PATCH] [lldb-dap] Treat empty thread names as unset
---
lldb/test/API/tools
https://github.com/DhruvSrivastavaX 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
Author: Hemang Gadhavi
Date: 2025-05-29T16:33:00+05:30
New Revision: f4e1ec55df92303b8ccd0d8475fc2ad3c1177bdc
URL:
https://github.com/llvm/llvm-project/commit/f4e1ec55df92303b8ccd0d8475fc2ad3c1177bdc
DIFF:
https://github.com/llvm/llvm-project/commit/f4e1ec55df92303b8ccd0d8475fc2ad3c1177bdc.diff
https://github.com/DhruvSrivastavaX closed
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
Author: Michael Buch
Date: 2025-05-29T12:06:29+01:00
New Revision: 7bd8e376fca22cac9593e93450a545573d3ff5f4
URL:
https://github.com/llvm/llvm-project/commit/7bd8e376fca22cac9593e93450a545573d3ff5f4
DIFF:
https://github.com/llvm/llvm-project/commit/7bd8e376fca22cac9593e93450a545573d3ff5f4.diff
Author: Jason Molenda
Date: 2025-05-29T01:30:02-07:00
New Revision: 57f3151a3144259f4e830fc43a1424e4c1f15985
URL:
https://github.com/llvm/llvm-project/commit/57f3151a3144259f4e830fc43a1424e4c1f15985
DIFF:
https://github.com/llvm/llvm-project/commit/57f3151a3144259f4e830fc43a1424e4c1f15985.diff
@@ -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
@@ -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
1 - 100 of 142 matches
Mail list logo
