https://github.com/Jlalond approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/142224
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/142224
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -104,7 +104,7 @@ TEST(Perf, RealLogicalCoreIDs) {
ASSERT_GT((int)cpu_ids->size(), 0) << "We must see at least one core";
}
-TEST(Perf, RealPtraceScope) {
+TEST(Perf, RealPtraceScopeWhenExist) {
Jlalond wrote:
This will probably fail, I don't think `kerne
@@ -74,7 +74,7 @@ lldb_private::process_linux::GetAvailableLogicalCoreIDs() {
llvm::Expected lldb_private::process_linux::GetPtraceScope() {
ErrorOr> ptrace_scope_file =
getProcFile("sys/kernel/yama/ptrace_scope");
- if (!*ptrace_scope_file)
+ if (!ptrace_scope_file)
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/142200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/142200
>From 05f09fa434c7fa925935337fb44740f1beba52ba Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 30 May 2025 12:02:02 -0700
Subject: [PATCH 1/3] Flip and add test
---
.../Plugins/Platform/Linux/PlatformL
@@ -0,0 +1,10 @@
+#include
Jlalond wrote:
I do think it's weird. Strangely enough all the existing SIGINFO shell tests
also live in this directory. I think it would lead to more confusion to break
that, but it's a great refactoring opportunity
https://github
@@ -0,0 +1,6 @@
+# XFAIL: system-darwin
Jlalond wrote:
Can you give me an example @dmpots? I would want to run this only on Linux
https://github.com/llvm/llvm-project/pull/142200
___
lldb-commits mailing list
lldb-comm
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/142200
>From 05f09fa434c7fa925935337fb44740f1beba52ba Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 30 May 2025 12:02:02 -0700
Subject: [PATCH 1/2] Flip and add test
---
.../Plugins/Platform/Linux/PlatformL
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/142200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/142200
>From 05f09fa434c7fa925935337fb44740f1beba52ba Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 30 May 2025 12:02:02 -0700
Subject: [PATCH] Flip and add test
---
.../Plugins/Platform/Linux/PlatformLinux
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/142200
>From ac33700e4b248fd9ee2bcb7ee12922fbe38ca5b2 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 30 May 2025 12:02:02 -0700
Subject: [PATCH] Flip and add test
---
lldb/test/Shell/Register/Core/Inputs/tki
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/142200
Despite a great review from @labath, I accidentally landed the signal with the
UID and PID properties flipped. I was actually trying to write tests for this
feature when I discovered it.
This fixes that bug,
Jlalond wrote:
Hey @DavidSpickett thanks for fixing the test.
I think you fixed it the right way, but I wanted to share my understanding of
how this probably happened
In ProcessElfCore, we check the siginfo status of all the threads
```
if (!siginfo_signal_found) {
// If we don't have s
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/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
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
Jlalond wrote:
```
MINIDUMP_MEMORY64_LIST:
NumberOfMemoryRanges = 0x0042
BaseRva = 0x7f1963c0
MemoryRanges[0] = [0x - 0x7f1a4020)
MemoryRanges[1] = [0x - 0x7f1e0820)
MemoryRanges[2] = [0x00
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
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
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
@@ -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:
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
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/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/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
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
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-
@@ -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 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
Jlalond wrote:
> What do you say to all this? I realize I am sort of asking you my pet
> feature, but I think that by framing your feature (debugging of dead
> processes) as a special case of this (debugging exiting processes), we can
> avoid most of the problematic issues with this PR (diverg
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/5] Reapply "[LLDB][ELF Core] Support all the Generic
(Negative
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/5] Reapply "[LLDB][ELF Core] Support all the Generic
(Negative
Jlalond wrote:
> but the I find the implementation somewhat unelegant.
😎 That's certainly me!
In all seriousness, I am still drinking from the proverbial firehouse. So I
appreciate the patience as I learn the codebase (even a year later).
You are correct, the checks are now unimportant becaus
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/4] Reapply "[LLDB][ELF Core] Support all the Generic
(Negative
Jlalond wrote:
@JDevlieghere Is there a way to trigger GreenDragon/Mac CI for this?
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/Jlalond created
https://github.com/llvm/llvm-project/pull/141670
After some debugging, I found out ProcessELFCore never updates the platform.
I've updated ProcessElfCore to set the arch and platform before we parse the
Notes.
>From 048cc769d6380bcb899bbcc5acf7f9349b51c5d3 M
Jlalond 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?
https://github.com/torvalds/linux/commit/8a
Jlalond wrote:
@JDevlieghere reverted while I investigate
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/Jlalond closed
https://github.com/llvm/llvm-project/pull/141645
___
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/141645
Reverts llvm/llvm-project#140150
Broke the Darwin tests, but they pass on Linux. Reverting to make the build
healthy while I investigate
>From 8da155e11c3d168d8f8ad59d4691156e57549d57 Mon Sep 17 00:00:00 2001
Jlalond wrote:
@felipepiovezan I am indeed the problem here. I'm confused how they're passing
on Linux but failing on Mac. I'll investigate.
https://github.com/llvm/llvm-project/pull/140150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
https://github.com/Jlalond closed
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/Jlalond 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
Jlalond wrote:
@DavidSpickett I'll make a follow up patch!
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
Jlalond wrote:
> Now for tests. The tests for the UnixSignals part are great, but I'm not sure
> if there's a test for the end-to-end flow. It possible this automatically
> code is tested by one of the existing core file. Could you check if anything
> breaks if you e.g. change GetDescriptionFr
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140150
>From 94d78d5ea7866fe896381319c875d6b9c3d34c90 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 13:57:11 -0700
Subject: [PATCH 01/12] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSi
@@ -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)
Jlalond wrote:
@labath So I moved the behavior to platform, I agree it's cleaner this way. 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
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140150
>From 94d78d5ea7866fe896381319c875d6b9c3d34c90 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 13:57:11 -0700
Subject: [PATCH 01/11] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSi
Jlalond wrote:
@DavidSpickett fixed the test, I gotcha'd myself checking an optional of a
bool. I added my gist to the description, let me know what you think
https://github.com/llvm/llvm-project/pull/137041
___
lldb-commits mailing list
lldb-commits@
https://github.com/Jlalond 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
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
>From 68077c22670ec044aab57bacb50c1edc0eb72eef Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 8 May 2025 12:56:14 -0700
Subject: [PATCH 1/2] Implement PTRACE_SEIZE when a process is coredumping
---
..
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
>From 68077c22670ec044aab57bacb50c1edc0eb72eef Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 8 May 2025 12:56:14 -0700
Subject: [PATCH] Implement PTRACE_SEIZE when a process is coredumping
---
.../Pr
Jlalond wrote:
@labath I think I misunderstand the vision you're trying to get at. Are you
suggesting we have Platform determine the Signal description and the
ProcessElfThread would call out to the platform_sp for it?
https://github.com/llvm/llvm-project/pull/140150
___
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/140162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
>From 0673dc530a91cb2dd1bdd60dd5136d64e4ed48e8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 16:37:06 -0700
Subject: [PATCH 1/3] Have interderminate events actually broadcast to dap
---
.
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
>From 0673dc530a91cb2dd1bdd60dd5136d64e4ed48e8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 16:37:06 -0700
Subject: [PATCH 1/3] Have interderminate events actually broadcast to dap
---
.
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 01/10] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSi
@@ -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->
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/9] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSign
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
>From 0673dc530a91cb2dd1bdd60dd5136d64e4ed48e8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 16:37:06 -0700
Subject: [PATCH 1/2] Have interderminate events actually broadcast to dap
---
.
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
>From 0673dc530a91cb2dd1bdd60dd5136d64e4ed48e8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 16:37:06 -0700
Subject: [PATCH 1/2] Have interderminate events actually broadcast to dap
---
.
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/8] Update ThreadElfCore
---
lldb/include/lldb/Target/UnixSign
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
@@ -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->
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
>From 0673dc530a91cb2dd1bdd60dd5136d64e4ed48e8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 15 May 2025 16:37:06 -0700
Subject: [PATCH 1/2] Have interderminate events actually broadcast to dap
---
.
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/140162
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-s
@@ -584,22 +584,26 @@ Status ELFLinuxSigInfo::Parse(const DataExtractor &data,
const ArchSpec &arch,
// 64b ELF have a 4 byte pad.
if (data.GetAddressByteSize() == 8)
offset += 4;
- // Not every stop signal has a valid address, but that will get resolved in
- // the
https://github.com/Jlalond 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
@@ -584,22 +584,26 @@ Status ELFLinuxSigInfo::Parse(const DataExtractor &data,
const ArchSpec &arch,
// 64b ELF have a 4 byte pad.
if (data.GetAddressByteSize() == 8)
offset += 4;
- // Not every stop signal has a valid address, but that will get resolved in
- // the
https://github.com/Jlalond 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/Jlalond created
https://github.com/llvm/llvm-project/pull/140150
Recently, I was on an issue that generated a large number of Coredumps, and
every time in both LLDB and GDB the signal was just `SIGSEGV`.
This was frustrating because we would expect a `SIGSEGV` to have an add
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/138169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/138169
>From ef04502d17c36044cd5fb96f333c328c8215f354 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 1 May 2025 10:11:10 -0700
Subject: [PATCH 1/7] Add new API to expose the expected size in bytes of a
core b
Jlalond wrote:
@dmpots Thanks for the feedback, I implemented several more test cases, and
fixed those typos.
https://github.com/llvm/llvm-project/pull/138169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/138169
>From ef04502d17c36044cd5fb96f333c328c8215f354 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 1 May 2025 10:11:10 -0700
Subject: [PATCH 1/6] Add new API to expose the expected size in bytes of a
core b
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-s
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
>From 42365065305d190aec3206f5d3eb35095050fb69 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 8 May 2025 12:56:14 -0700
Subject: [PATCH] Implement PTRACE_SEIZE when a process is coredumping
---
.../Pr
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
>From fa08811c7a90b9fd1c644b051ed3d7d1157243fe Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 8 May 2025 12:56:14 -0700
Subject: [PATCH] Implement PTRACE_SEIZE when a process is coredumping
---
.../ll
Jlalond wrote:
@labath @DavidSpickett Thanks for the patience.
I've broken down my prototype, and this is now patch 2, where we implement the
SEIZE functionality. I will follow up with making it so we can't resume the
process when we're in this state.
@DavidSpickett you mentioned you wanted m
https://github.com/Jlalond ready_for_review
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
https://github.com/Jlalond 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
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/137041
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-s
Jlalond wrote:
@clayborg, @dmpots bump if you have time
https://github.com/llvm/llvm-project/pull/138169
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/138943
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/138943
___
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/138943
Add a generous amount of buffer directories. I found out some LLDB forks
(internal and external) had custom ranges that could fail because we didn't
pre-account for those. To prevent this from being a problem,
https://github.com/Jlalond approved this pull request.
Thanks @ashgti!
https://github.com/llvm/llvm-project/pull/138918
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/138580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/138580
>From 03d5449b30f414e2a3f322f102101dc4b2c05c4f Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 5 May 2025 11:33:05 -0700
Subject: [PATCH 1/3] Add IsCoredumping to ProcessInfo to use in the future of
the
@@ -213,6 +213,11 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
&ProcessInfo,
} else if (Line.consume_front("Tgid:")) {
Line = Line.ltrim();
Line.consumeInteger(10, Tgid);
+} else if (Line.consume_front("CoreDumping:")) {
+ uint32_t cor
@@ -115,5 +115,8 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
}
ASSERT_TRUE(Info.IsZombie().has_value());
ASSERT_FALSE(Info.IsZombie().value());
+
+ ASSERT_TRUE(Info.IsCoreDumping().has_value());
+ ASSERT_FALSE(Info.IsCoreDumping().value());
Jlalon
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/138580
___
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/138580
This is the first useful patch in the series related to enabling `PTRACE_SEIZE`
for processes Coredumping. In order to make the decision if we want to seize or
attach, we need to expose that in processinfo.
We
@@ -161,7 +157,13 @@ void AttachRequestHandler::operator()(const
llvm::json::Object &request) const {
dap.target.ConnectRemote(listener, connect_url.c_str(), "gdb-remote",
error);
} else {
-// Attach by process name or id.
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/138206
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1 - 100 of 774 matches
Mail list logo
