ashgti wrote:
#140331 will also fix this underlying issue. I think its a better approach to
fix this without having to listen for all events.
https://github.com/llvm/llvm-project/pull/140142
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
ht
https://github.com/ashgti closed
https://github.com/llvm/llvm-project/pull/140299
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ashgti closed
https://github.com/llvm/llvm-project/pull/140331
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: John Harrison
Date: 2025-05-16T19:28:34-07:00
New Revision: 0e0b501bf53677105b539fa4f84cbfb76c46f74d
URL:
https://github.com/llvm/llvm-project/commit/0e0b501bf53677105b539fa4f84cbfb76c46f74d
DIFF:
https://github.com/llvm/llvm-project/commit/0e0b501bf53677105b539fa4f84cbfb76c46f74d.diff
github-actions[bot] wrote:
@LauraElanorJones Congratulations on having your first Pull Request (PR) merged
into the LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/140331
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
github-actions[bot] wrote:
⚠️ We detected that you are using a GitHub private e-mail address to contribute
to the repo. Please turn off [Keep my email addresses
private](https://github.com/settings/emails) setting in your account. See
[LLVM
Discourse](https://discourse.llvm.org/t/hidden-email
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/140333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: LauraElanorJones
Date: 2025-05-16T19:17:03-07:00
New Revision: 9178a1720667807aa46dcfc3069bad7e8fef5f2e
URL:
https://github.com/llvm/llvm-project/commit/9178a1720667807aa46dcfc3069bad7e8fef5f2e
DIFF:
https://github.com/llvm/llvm-project/commit/9178a1720667807aa46dcfc3069bad7e8fef5f2e.di
JDevlieghere wrote:
> Looks like all the tests are passing on linux and for me locally on macOS as
> well.
All the macOS tests are passing for me as well.
https://github.com/llvm/llvm-project/pull/140331
___
lldb-commits mailing list
lldb-commits@lis
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/140333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140331
>From 5c77f71128e01db1a3926d0de06f2d4d55cb80e0 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 18:35:28 -0700
Subject: [PATCH 1/2] [lldb-dap] Take two at refactoring the startup sequence.
Thi
https://github.com/LauraElanorJones created
https://github.com/llvm/llvm-project/pull/140333
Fix code block formatting in section "The Decision Point Breakpoint Commands"
>From 7d235fe77df46cfe2525cbed2a9944a6f208a613 Mon Sep 17 00:00:00 2001
From: LauraElanorJones <164247463+lauraelanorjo...@u
ashgti wrote:
Looks like all the tests are passing on linux and for me locally as well.
> The only thing I don't like is that the configurationDone is now once again
> implicit. In a future PR, I'd love to move the tests to a model where we
> specify that explicitly after doing the breakpoints
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
This is more straight forward refactor of the startup sequence that reverts
parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt,
I ended up removing the pending request queue and not
https://github.com/ashgti ready_for_review
https://github.com/llvm/llvm-project/pull/140331
___
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.
I think you can move this out of draft. I'm thoroughly convinced that my first
stab at this is wrong. The code LGTM and I like that we don't have to launch
everything with `stopOnEntry`.
The only thing I don't like is that the config
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (LauraElanorJones)
Changes
Fix code block formatting in section "The Decision Point Breakpoint Commands"
---
Full diff: https://github.com/llvm/llvm-project/pull/140333.diff
1 Files Affected:
- (modified) lldb/docs/use/python.rst (+
ashgti wrote:
@da-viper I think this version may be a bit cleaner for
https://github.com/llvm/llvm-project/issues/140154, let me know if that works
for you
https://github.com/llvm/llvm-project/pull/140331
___
lldb-commits mailing list
lldb-commits@li
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/140331
This is more straight forward refactor of the startup sequence that reverts
parts of ba29e60f9abd5e883579bb78db13fc5a7588. Unlike my previous attempt,
I ended up removing the pending request queue and not in
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140331
>From 5c77f71128e01db1a3926d0de06f2d4d55cb80e0 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 18:35:28 -0700
Subject: [PATCH] [lldb-dap] Take two at refactoring the startup sequence.
This is
ashgti wrote:
I think #140331 is a cleaner way to solve this without the need for an
`AsyncRequestHandler`. We may still want the `AsyncRequestHandler` in the
future, but at least for now, I think we can avoid its added complexity.
https://github.com/llvm/llvm-project/pull/140299
_
JDevlieghere wrote:
I took a look at the code and I think the approach looks good.
I wonder if there's an opportunity to make this slightly more generic to avoid
(1) having to change the interface (i.e. keep returning an `llvm::Error`) and
(2) defer the error response so there's no divergence
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/140325
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
JDevlieghere wrote:
I also found this diagram which covers both cases I had in mind:
https://github.com/microsoft/vscode/issues/4902#issuecomment-368583522
https://github.com/llvm/llvm-project/pull/140299
___
lldb-commits mailing list
lldb-commits@lis
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kazu Hirata (kazutakahirata)
Changes
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary in
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/140325
EmplaceSafeString accepts StringRef for the last parameter, str, and
then internally creates a copy of str via StringRef::str or
llvm::json::fixUTF8, so caller do not need to create their own
temporary ins
JDevlieghere wrote:
One more thing that comes to mind: how confident are we that all existing
clients send the launch/attach in parallel with the configuration requests? If
we implement what you suggest, we risk a potential deadlock when a client waits
for the launch/attach to complete before
JDevlieghere wrote:
Thanks for the summary and especially calling out that the launch and the
configuration tracks are happening _in parallel_, I hadn't realized that until
now. That explains what the "PAR" stands for in the sequence diagram... Things
make a lot more sense now :-)
Alright, ye
Jlalond wrote:
@labath
I refactored to the best of my ability the signal parsing. Thankfully even
getting `thread siginfo` working.
However I'm unhappy with how I'm handling the ValueObject in the Linux Signals,
I couldn't find an easy way to make this into some generic siginfo linux type,
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140150
>From 86ec6c076b9cf8e7afeb7d6bb0e334434f6e0d9e Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 13:57:11 -0700
Subject: [PATCH 1/7] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSign
ashgti wrote:
> That said, does this actually solve the underlying problems? We know that VS
> Code sends the launch and attach request before configuration done. It's
> equally valid to not do that, and do things the way they're shown in the
> sequence diagram, where you set breakpoints, then
JDevlieghere wrote:
I haven't looked at the code yet. I was re-reading the launch sequence part of
the spec [1] to make sure this still complies, and I believe it does because
the spec talks about _responding_ to the request, not about _handling_ it.
> After the response to configurationDone
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/138209
>From dcb5b2596267d908dea1474164a1fadf1cd23aef Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Thu, 1 May 2025 14:51:24 -0700
Subject: [PATCH 1/5] [lldb][Formatters] Add --pointer-match-depth option to
"type su
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH 1/3] [lldb-dap] Adjusting startup flow to better handle async
ope
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH 1/2] [lldb-dap] Adjusting startup flow to better handle async
ope
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/140299
>From 59aadc0f2b61a39563269329d10c553f7965c70b Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 16 May 2025 12:03:50 -0700
Subject: [PATCH] [lldb-dap] Adjusting startup flow to better handle async
operati
da-viper wrote:
@ashgti please could you rebase the branch as there is some risv commit that
failed on the CI, will test it over the weekend.
https://github.com/llvm/llvm-project/pull/140299
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
ashgti wrote:
@JDevlieghere @da-viper I think this may work to resolve
https://github.com/llvm/llvm-project/issues/140154 and the underlying issue I
saw in #140142 without needing to change our broadcaster. Leaving as a draft
for now, but all the tests are passing with this change.
https://gi
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/140299
This introduces an `AsyncRequestHandler` and partially reverse the changes from
ba29e60f9abd5e883579bb78db13fc5a7588 in that the `launch` and `attach`
commands now run when we receive them. We wait to send t
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->
da-viper wrote:
> Would it be possible to have the RequestHandlers advertise whether or not
> they should be deferred until the configuration is done (e.g.
> DeferredUntilConfigurationDone), and keep the latter an implementation detail
> of the DAP class? And strictly handle deferring at the q
ashgti wrote:
Okay, to summarize my previous comment, I think we could address this in the
following ways:
1. Listen for the broadcast class instead of a specific broadcaster. The
downside here is we may see events for targets/processes we're not directly
interested in.
1. In the setBreakpoin
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->
@@ -77,16 +77,19 @@ ProgressEvent::Create(uint64_t progress_id,
std::optional message,
if (event.GetEventType() == progressStart && event.GetEventName().empty())
return std::nullopt;
- if (prev_event && prev_event->EqualsForIDE(event))
+ if (prev_event && prev_event->
ashgti wrote:
> Is it possible to delay _setting_ the breakpoint until we know what the
> target is? Or will that be a problem because attach/launchCommands will
> already resume the process? Could we require that the target is created
> inside `preRunCommands` or `initCommands`?
Previously,
@@ -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
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/138551
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
Author: nd
Date: 2025-05-16T09:09:50-07:00
New Revision: c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2
URL:
https://github.com/llvm/llvm-project/commit/c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2
DIFF:
https://github.com/llvm/llvm-project/commit/c72c0b298c13ebc4d374e84b8ea20f8ca4f5ace2.diff
LOG: Fix r
github-actions[bot] wrote:
@nd Congratulations on having your first Pull Request (PR) merged into the LLVM
Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with a build, you
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_ex
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/139862
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere commented:
I like the idea of making the request handlers responsible for telling us
whether they should be deferred compared to the allow-list I implemented.
That's definitely an improvement.
What I don't like is how this introduces more statefulness, especial
https://github.com/ashgti closed
https://github.com/llvm/llvm-project/pull/140107
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: John Harrison
Date: 2025-05-16T08:47:01-07:00
New Revision: 087a5d2ec7897cd99d3787820711fec76a8e1792
URL:
https://github.com/llvm/llvm-project/commit/087a5d2ec7897cd99d3787820711fec76a8e1792
DIFF:
https://github.com/llvm/llvm-project/commit/087a5d2ec7897cd99d3787820711fec76a8e1792.diff
@@ -60,7 +60,7 @@ def test_breakpoint_events(self):
response = self.dap_server.request_setBreakpoints(
main_source_path, [main_bp_line]
)
-self.assertTrue(response)
+self.assertTrue(response["success"])
ashgti wrote:
@@ -748,7 +748,7 @@ bool DAP::HandleObject(const Message &M) {
dispatcher.Set("client_data",
llvm::Twine("request_command:", req->command).str());
if (handler_pos != request_handlers.end()) {
- handler_pos->second->Run(*req);
+ defer = handl
@@ -46,7 +46,14 @@ class BaseRequestHandler {
virtual ~BaseRequestHandler() = default;
- void Run(const protocol::Request &);
+ /// Return `true` if the request should be deferred.
+ [[nodiscard]]
+ bool Run(const protocol::Request &);
+
+ [[nodiscard]]
+ virtual bool
jmorse wrote:
This disappeared into a black hole in my inbox sorry; step forwards @SLTozer!
(We're not rated for the reader-side of things but can probably comment on the
writer).
https://github.com/llvm/llvm-project/pull/139175
___
lldb-commits mail
Sterling-Augustine wrote:
Anyone?
https://github.com/llvm/llvm-project/pull/139175
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Ebuka Ezike (da-viper)
Changes
Fixes #140154
Basic implementation of defering requests.
It no longer depends on a white list of request, So if there is any future
breakpoint types added to the DAP specification. it will not break existin
https://github.com/da-viper updated
https://github.com/llvm/llvm-project/pull/140260
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
@@ -666,7 +667,9 @@ lldb::offset_t lldb_private::DumpDataExtractor(
const unsigned format_precision = 0;
const llvm::fltSemantics &semantics =
- GetFloatSemantics(target_sp, item_byte_size);
+ item_format == eFormatFloat128 && item_byte_size == 16
https://github.com/beetrees updated
https://github.com/llvm/llvm-project/pull/98369
>From b96a6a1b6ef96702461a6cf32b361847c318bf8a Mon Sep 17 00:00:00 2001
From: beetrees
Date: Wed, 10 Jul 2024 18:49:45 +0100
Subject: [PATCH] [lldb] Add support for displaying `__float128` variables
---
lldb/b
https://github.com/da-viper created
https://github.com/llvm/llvm-project/pull/140260
Fixes #140154
Basic implementation of defering requests.
It no longer depends on a white list of request, So if there is any future
breakpoint types added to the DAP specification. it will not break existing
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Michael Buch (Michael137)
Changes
A user ran into an issue where the libc++ std::unordered_map` formatter fails
because it can't deduce the `element_type`. That happens because the
`node_type` is a forwad declaration. And, in fact, dsymuti
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/140256
A user ran into an issue where the libc++ std::unordered_map` formatter fails
because it can't deduce the `element_type`. That happens because the
`node_type` is a forwad declaration. And, in fact, dsymutil
Author: Dhruv Srivastava
Date: 2025-05-16T17:40:13+05:30
New Revision: c02e6ca3b3ea84566800043bb4c29c67eb63f223
URL:
https://github.com/llvm/llvm-project/commit/c02e6ca3b3ea84566800043bb4c29c67eb63f223
DIFF:
https://github.com/llvm/llvm-project/commit/c02e6ca3b3ea84566800043bb4c29c67eb63f223.di
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/102601
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Ari
https://github.com/DhruvSrivastavaX closed
https://github.com/llvm/llvm-project/pull/139875
___
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/139875
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Ari
mstorsjo wrote:
> > Therefore, this situation should only be an issue with older kernels, so
> > perhaps it not something that regular user mode applications should need to
> > worry about (unless specifically wanting to run with older kernels).
>
> I will test this PR with an older kernel as
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
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
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
@@ -193,7 +188,7 @@ class LLDB_API SBValue {
/// and also if the target can be run to figure out the dynamic
/// type of the child value.
///
- /// \param[in] can_create_synthetic
+ /// \param[in] use_synthetic
labath wrote:
Sounds good. I wasn
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/140065
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
DavidSpickett wrote:
I think there are kernel issues that need to be fixed before all the LLDB
features can work. So don't waste your own time on this right now, I will
coordinate with Arm's kernel team to get this working.
https://github.com/llvm/llvm-project/pull/135563
_
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/139875
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -191,20 +193,36 @@ void ObjectFileXCOFF::ParseSymtab(Symtab &lldb_symtab) {}
bool ObjectFileXCOFF::IsStripped() { return false; }
void ObjectFileXCOFF::CreateSections(SectionList &unified_section_list) {
+
if (m_sections_up)
return;
m_sections_up = std::make_un
@@ -97,14 +97,26 @@ class ObjectFileXCOFF : public lldb_private::ObjectFile {
lldb::DataBufferSP header_data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+ struct XCOFF32 {
+using SectionHeader = llvm::object::XCOFF
https://github.com/labath approved this pull request.
Looks fine. Ship it.
https://github.com/llvm/llvm-project/pull/139875
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
nd wrote:
Sorry, I haven't read the LLVM GitHub user guide before submitting the PR and
didn't realize that force pushes are to be avoided.
Please let me know if I need to rework the request somehow.
https://github.com/llvm/llvm-project/pull/139862
_
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
@@ -111,7 +111,42 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
llvm_unreachable("invalid token kind");
}
}
- return ParsePrimaryExpression();
+ return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+// postfix_expression:
+//primary_ex
84 matches
Mail list logo
