https://github.com/JDevlieghere commented:
I like the idea of looking for Make at configuration time. However, I think if
we go that route, we should pass make as an explicit argument to `dotest.py`:
- We do for other tools that we find at configuration time (such as
`dsymutil`).
- It elimin
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/109477
>From 73880b94c09f1a9a9233f80f7eb70b4f68cbf6aa Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 01/13] Add Process code to get the fs_base region and the
.tdata
@@ -3180,15 +3180,24 @@ void
CommandInterpreter::IOHandlerInputComplete(IOHandler &io_handler,
if ((result.Succeeded() &&
io_handler.GetFlags().Test(eHandleCommandFlagPrintResult)) ||
io_handler.GetFlags().Test(eHandleCommandFlagPrintErrors)) {
-// Display a
jimingham wrote:
You didn't introduce the situation where we have two separate
"ExpressionResults -> String" API's in different places, but you did move one,
so maybe it's time to put them together? I don't have a strong opinion where
they should go, except together if possible...
I'll still
@@ -0,0 +1,79 @@
+//===-- DiagnosticsRendering.h --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -138,7 +138,10 @@ class LLDB_API SBUnixSignals;
typedef bool (*SBBreakpointHitCallback)(void *baton, lldb::SBProcess &process,
lldb::SBThread &thread,
lldb::SBBreakpointLocation &location);
-
+ty
@@ -569,6 +569,18 @@ class Debugger : public
std::enable_shared_from_this,
SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
void *baton);
+ /// Add a notification callback when notification type event happens. Return
a
--
@@ -569,6 +569,18 @@ class Debugger : public
std::enable_shared_from_this,
SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
void *baton);
+ /// Add a notification callback when notification type event happens. Return
a
+ ///
@@ -1362,6 +1362,12 @@ enum Severity {
eSeverityInfo, // Equivalent to Remark used in clang.
};
+enum NotificationType {
+ eDebuggerWillBeCreated = (1 << 0),
jimingham wrote:
Yes, it's not useful to call this before the new Debugger is fully initialized.
https://github.com/medismailben approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/111560
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
bulbazord wrote:
+1 to what Jonas said. Making `dotest.py` more explicit makes reproducing test
behavior more reliable. :)
https://github.com/llvm/llvm-project/pull/111531
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.or
@@ -1362,6 +1362,12 @@ enum Severity {
eSeverityInfo, // Equivalent to Remark used in clang.
};
+enum NotificationType {
+ eDebuggerWillBeCreated = (1 << 0),
clayborg wrote:
Should this be `eDebuggerWasCreated` to indicate that a debugger object was
creat
@@ -138,7 +138,10 @@ class LLDB_API SBUnixSignals;
typedef bool (*SBBreakpointHitCallback)(void *baton, lldb::SBProcess &process,
lldb::SBThread &thread,
lldb::SBBreakpointLocation &location);
-
+ty
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/109477
>From 73880b94c09f1a9a9233f80f7eb70b4f68cbf6aa Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 01/14] Add Process code to get the fs_base region and the
.tdata
labath wrote:
Thanks for the quick response, Jason.
I think it's quite possible that you haven't run into this situation before,
because the final representation depends on what tool was used to split the
functions. Judging by the name (`cold.1`), I think you're using the llvm
"hot-cold-split
labath wrote:
At least back when I was looking at this problem (5+ years ago), memory mapping
was the key -- I was not able to delete the process if the file was mapped --
regardless of the open flags. That said, [this
comment](https://github.com/llvm/llvm-project/blob/4d218caa7716743061e8d34d
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/110856
___
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
`sanitizer-aarch64-linux-fuzzer` running on `sanitizer-buildbot11` while
building `libcxx` at step 2 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/159/builds/7709
Here is the relevant pi
jeffreytan81 wrote:
> > I think we can do better than save at memory region fidelity which is at
> > least at page boundary if I am not wrong.
>
> > We can use type information to query and save the object's size without
> > including hundreds of unrelated objects in the
> > heap happen to be
igorkudrin wrote:
> To make the test more representative, I suggeest replacing the `removeFile()`
> method with the following:
Thanks! I've updated the test as you suggested.
https://github.com/llvm/llvm-project/pull/111237
___
lldb-commits mailing l
https://github.com/igorkudrin updated
https://github.com/llvm/llvm-project/pull/111237
>From 6756842b1c78ac6f41fa467f112aa7632f260582 Mon Sep 17 00:00:00 2001
From: Igor Kudrin
Date: Fri, 4 Oct 2024 23:27:04 -0700
Subject: [PATCH 1/2] [lldb] Fix and re-enable TestUseSourceCache.py
The decorato
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
1809d0fa1c15b16ca94381d8be3ef70c4a83c36b...433f6efa4657494c9b9a5581f3fa2b5b2299ff24
lldb/
@@ -273,8 +273,14 @@ void ProcessMinidump::RefreshStateAfterStop() {
// No stop.
return;
}
-
- stop_info = StopInfo::CreateStopReasonWithSignal(*stop_thread, signo);
+ const char *description = nullptr;
+ if (exception_stream.ExceptionRecord
@@ -0,0 +1,79 @@
+//===-- DiagnosticsRendering.h --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/110065
>From 57e287fbd426306d2ebc3a39d8ed8e8b7309a79c Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 24 Sep 2024 17:42:49 -0700
Subject: [PATCH 01/13] Add the addr info when appropriate for NIX' crash
signals
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108448
>From 7bdbce7ef2f60e819dea296ff8da832c1acbaef6 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 12 Sep 2024 13:10:58 -0700
Subject: [PATCH 01/10] Create set for the stop reasons we collect, and add
break
jimingham wrote:
I couldn't see what the `original_callback` argument and ivar are for? They
just seem to get copied around but not used?
We should also add a command way to add these, but it doesn't make sense to do
that for the debugger created and destroyed ones because the command
interp
@@ -1362,6 +1362,12 @@ enum Severity {
eSeverityInfo, // Equivalent to Remark used in clang.
};
+enum NotificationType {
jimingham wrote:
Might be good to put a comment here saying (a) this is used for
SBNotificationCallbacks and (b) this is where you shou
@@ -737,19 +752,35 @@ class Debugger : public
std::enable_shared_from_this,
lldb::TargetSP m_dummy_target_sp;
Diagnostics::CallbackID m_diagnostics_callback_id;
- std::mutex m_destroy_callback_mutex;
- lldb::callback_token_t m_destroy_callback_next_token = 0;
- struct
https://github.com/igorkudrin updated
https://github.com/llvm/llvm-project/pull/111483
>From bb594335d05a4c8cb2949556f5b338242a9b5280 Mon Sep 17 00:00:00 2001
From: Igor Kudrin
Date: Mon, 7 Oct 2024 22:07:02 -0700
Subject: [PATCH 1/2] [lldb] Fix TestGlobalModuleCache.py for remote debugging
`S
labath wrote:
> * I can append to the file from Python (mode="a")
>
> * I can delete the file from Python (what the current test is doing)
>
> * I cannot delete the file from File Explorer => says lldb.exe is using the
> file
>
> * I cannot overwrite the file from Python (mode="w")
>
> * I c
@@ -111,6 +111,8 @@ def do_test(self, one_target, one_debugger):
else:
if one_target:
new_debugger = lldb.SBDebugger().Create()
+if lldb.selected_platform is not None:
+new_debugger.SetSelectedPlatform(lldb
https://github.com/igorkudrin updated
https://github.com/llvm/llvm-project/pull/111483
>From bb594335d05a4c8cb2949556f5b338242a9b5280 Mon Sep 17 00:00:00 2001
From: Igor Kudrin
Date: Mon, 7 Oct 2024 22:07:02 -0700
Subject: [PATCH 1/2] [lldb] Fix TestGlobalModuleCache.py for remote debugging
`S
Author: Chelsea Cassanova
Date: 2024-10-08T10:12:01-07:00
New Revision: ababa483b2ff31357f8c504b1110e255a56ff762
URL:
https://github.com/llvm/llvm-project/commit/ababa483b2ff31357f8c504b1110e255a56ff762
DIFF:
https://github.com/llvm/llvm-project/commit/ababa483b2ff31357f8c504b1110e255a56ff762.d
https://github.com/chelcassanova closed
https://github.com/llvm/llvm-project/pull/111560
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: AbdAlRahman Gad
Date: 2024-10-08T10:04:52-07:00
New Revision: 6f2ebc435f1cd8f121d227a52c76b6477cec8c91
URL:
https://github.com/llvm/llvm-project/commit/6f2ebc435f1cd8f121d227a52c76b6477cec8c91
DIFF:
https://github.com/llvm/llvm-project/commit/6f2ebc435f1cd8f121d227a52c76b6477cec8c91.dif
https://github.com/adrian-prantl closed
https://github.com/llvm/llvm-project/pull/110718
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/adrian-prantl approved this pull request.
https://github.com/llvm/llvm-project/pull/110718
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Jlalond wrote:
> I think we can do better than save at memory region fidelity which is at
> least at page boundary if I am not wrong.
> We can use type information to query and save the object's size without
> including hundreds of unrelated objects in the
> heap happen to be in the same page
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/111601
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -6528,6 +6528,75 @@ static void AddRegion(const MemoryRegionInfo ®ion,
bool try_dirty_pages,
CreateCoreFileMemoryRange(region));
}
+static void AddSegmentRegisterSections(Process &process, ThreadSP &thread_sp,
Jlalond wrote:
In the DYLD, d
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/109477
>From 73880b94c09f1a9a9233f80f7eb70b4f68cbf6aa Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 01/15] Add Process code to get the fs_base region and the
.tdata
https://github.com/igorkudrin updated
https://github.com/llvm/llvm-project/pull/111237
>From 6756842b1c78ac6f41fa467f112aa7632f260582 Mon Sep 17 00:00:00 2001
From: Igor Kudrin
Date: Fri, 4 Oct 2024 23:27:04 -0700
Subject: [PATCH] [lldb] Fix and re-enable TestUseSourceCache.py
The decorators c
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/111543
I don't see an obvious reason it has to be x86 specific and local testing on
Arm and AArch64 is fine.
Originally disabled in 50337fb933e0f666d34d747a43d46840b3982bf7 in response to
failures apparently ca
DavidSpickett wrote:
Noticed this looking at a failure from
https://github.com/llvm/llvm-project/pull/106919, which I think was unrelated.
If this lands and our bot blows up I'll just revert this.
https://github.com/llvm/llvm-project/pull/111543
___
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
I don't see an obvious reason it has to be x86 specific and local testing on
Arm and AArch64 is fine.
Originally disabled in 50337fb933e0f666d34d747a43d46840b3982bf7 in response to
failures apparentl
https://github.com/labath commented:
It's not clear to me what's up with the idea of moving the saving code to the
dynamic loader plugin. Is that something you plan to work on?
The main thing that bothers me is the `AddLinkMapSections` function. Although
it superficially generic, it uses the `
@@ -462,7 +475,6 @@ ModuleSP ProcessMinidump::GetOrCreateModule(UUID
minidump_uuid,
void ProcessMinidump::ReadModuleList() {
std::vector filtered_modules =
m_minidump_parser->GetFilteredModuleList();
-
labath wrote:
please revert random whitespace cha
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -6528,6 +6528,75 @@ static void AddRegion(const MemoryRegionInfo ®ion,
bool try_dirty_pages,
CreateCoreFileMemoryRange(region));
}
+static void AddSegmentRegisterSections(Process &process, ThreadSP &thread_sp,
labath wrote:
This name is ve
@@ -333,6 +336,16 @@ ArchSpec ProcessMinidump::GetArchitecture() {
return ArchSpec(triple);
}
+DataExtractor ProcessMinidump::GetAuxvData() {
+ std::optional> auxv =
+ m_minidump_parser->GetStream(StreamType::LinuxAuxv);
+ if (!auxv)
+return DataExtractor();
+
+
@@ -83,7 +83,11 @@ ModuleSP DynamicLoader::GetTargetExecutable() {
ModuleSpec module_spec(executable->GetFileSpec(),
executable->GetArchitecture());
auto module_sp = std::make_shared(module_spec);
-
+ // If we're a coredump and we a
Author: David Spickett
Date: 2024-10-08T08:56:21Z
New Revision: 7c1087613bb9f4ceebb991e5a4b2ef4d5adb4dfa
URL:
https://github.com/llvm/llvm-project/commit/7c1087613bb9f4ceebb991e5a4b2ef4d5adb4dfa
DIFF:
https://github.com/llvm/llvm-project/commit/7c1087613bb9f4ceebb991e5a4b2ef4d5adb4dfa.diff
LOG
Author: David Spickett
Date: 2024-10-08T08:58:43Z
New Revision: ec009994a06338995dfb6431c943b299f9327fd2
URL:
https://github.com/llvm/llvm-project/commit/ec009994a06338995dfb6431c943b299f9327fd2
DIFF:
https://github.com/llvm/llvm-project/commit/ec009994a06338995dfb6431c943b299f9327fd2.diff
LOG
dzhidzhoev wrote:
@DavidSpickett thank you for the fixes!
https://github.com/llvm/llvm-project/pull/110837
___
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: Stefan Gränitz (weliveindetail)
Changes
Around 400 of LLDB's dotest.py based tests require the `make` tool to be found
in Path. If it's not found, they fail with an obscure error and show up as
`UNRESOLVED`. llvm-lit takes care of MSYS bas
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/111531
Around 400 of LLDB's dotest.py based tests require the `make` tool to be found
in Path. If it's not found, they fail with an obscure error and show up as
`UNRESOLVED`. llvm-lit takes care of MSYS based t
Author: David Spickett
Date: 2024-10-08T14:29:08Z
New Revision: 98c9c1a4d2d4fc41b34f73e4630de435c9c0c396
URL:
https://github.com/llvm/llvm-project/commit/98c9c1a4d2d4fc41b34f73e4630de435c9c0c396
DIFF:
https://github.com/llvm/llvm-project/commit/98c9c1a4d2d4fc41b34f73e4630de435c9c0c396.diff
LOG
DavidSpickett wrote:
I suspect a missing unsupported annotation:
```
UNSUPPORTED: LLDB
(/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang-arm) ::
test_FakeAttachedRunInTerminalLauncherAndCheckEnvironment
(TestDAP_runInTerminal.TestDAP_runInTerminal) (skipping due to the following
par
antmox wrote:
Hi! Looks like this patch broke lldb-arm-ubuntu bot :
https://lab.llvm.org/buildbot/#/builders/18/builds/5041
> Failed Tests (1):
> lldb-api :: tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py
Could you please look at this ?
https://github.com/llvm/llvm-project/pull/106919
labath wrote:
Hello all,
I'm parachuting in here because we also have a use case that might benefit from
something like this. In our case, we want to run some actions (set up data
formatters, source paths, etc.) if we find that we're working with a certain
kind of binary (which contains infor
@@ -83,7 +83,11 @@ ModuleSP DynamicLoader::GetTargetExecutable() {
ModuleSpec module_spec(executable->GetFileSpec(),
executable->GetArchitecture());
auto module_sp = std::make_shared(module_spec);
-
+ // If we're a coredump and we a
Jlalond wrote:
> The main thing that bothers me is the AddLinkMapSections function. Although
> it superficially generic, it uses the GetImageInfoAddress, which is only
> implemented by ObjectFileELF, and only called from the elf-core and
> posix-dyld plugins (i.e. code which already knows its
Author: Igor Kudrin
Date: 2024-10-08T17:46:02-07:00
New Revision: c80f48491b150197d758f0906011b44472fa2dd5
URL:
https://github.com/llvm/llvm-project/commit/c80f48491b150197d758f0906011b44472fa2dd5
DIFF:
https://github.com/llvm/llvm-project/commit/c80f48491b150197d758f0906011b44472fa2dd5.diff
L
https://github.com/igorkudrin closed
https://github.com/llvm/llvm-project/pull/111231
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
emrekultursay wrote:
OK, I figured the problem. In the test, we call `os.removeFile()` which does
not actually represent the real end-user use-case (which is to edit the file
and save it).
Empirically, on Windows 11, I can verify that when LLDB mmaps these large
files, then:
1. I can appen
vogelsgesang wrote:
friendly ping, @walter-erquinigo @clayborg
https://github.com/llvm/llvm-project/pull/104589
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
> On Oct 8, 2024, at 2:16 AM, Pavel Labath ***@***.***> wrote:
>
>
> Hello all,
>
> I'm parachuting in here because we also have a use case that might benefit
> from something like this. In our case, we want to run some actions (set up
> data formatters, source paths, etc.
jimingham wrote:
> On Oct 8, 2024, at 9:53 AM, Jim Ingham ***@***.***> wrote:
>
>>
>>
>>
>>> On Oct 8, 2024, at 2:16 AM, Pavel Labath ***@***.***> wrote:
>>>
>>>
>>> Hello all,
>>>
>>> I'm parachuting in here because we also have a use case that might benefit
>>> from something like thi
jurahul wrote:
Sounds good. thanks.
https://github.com/llvm/llvm-project/pull/110692
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jurahul closed
https://github.com/llvm/llvm-project/pull/110692
___
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/111601
This adds an extension to allow the saving of a Thread and it's pointers N
layers deep via BFS. This lets SBSaveCore 'automagically' figure out everything
important for a given thread to save on your behalf.
>
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/111601
>From b128131f457a013102b2a0b2fcb968956d980076 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 8 Oct 2024 15:52:45 -0700
Subject: [PATCH 1/2] Create new extension for save core to save a thread and N
po
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
This adds an extension to allow the saving of a Thread and it's pointers N
layers deep via BFS. This lets SBSaveCore 'automagically' figure out everything
important for a given thread to save on your behalf.
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
-
https://github.com/walter-erquinigo approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/111543
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/111560
SBTypeStaticField was missing from SBDefines, this commit adds the class there.
>From db7d2f7cc126e348e7c524f19196fca42a6142c9 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Tue, 8 Oct 2024 10:01:
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
SBTypeStaticField was missing from SBDefines, this commit adds the class there.
---
Full diff: https://github.com/llvm/llvm-project/pull/111560.diff
1 Files Affected:
- (modified) lldb/include/ll
https://github.com/jeffreytan81 edited
https://github.com/llvm/llvm-project/pull/111206
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jeffreytan81 wrote:
The PR is revised based on feedback. In this PR, it supports
`eDebuggerWillBeCreated` and `eDebuggerWillBeDestroyed` notifications. We can
add more in future. The callback is only called if the type filtering matches
(for example, the client asks for `eDebuggerWillBeCreated
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/111206
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/2] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
https://github.com/jeffreytan81 updated
https://github.com/llvm/llvm-project/pull/111206
>From 6e84ab9a14e63c58e1facdbf9a695c093882b37b Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Mon, 19 Aug 2024 10:57:35 -0700
Subject: [PATCH 1/2] Fix StartDebuggingRequestHandler/ReplModeRequestHandler
https://github.com/jeffreytan81 edited
https://github.com/llvm/llvm-project/pull/111206
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,79 @@
+//===-- DiagnosticsRendering.h --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
github-actions[bot] wrote:
@AbdAlRahmanGad 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
@@ -470,6 +471,27 @@ def save_core_with_region(self, process, region_index):
if os.path.isfile(custom_file):
os.unlink(custom_file)
+def save_core_one_thread_one_heap(self, process, region_index):
jeffreytan81 wrote:
Who is inv
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
https://github.com/jeffreytan81 requested changes to this pull request.
I think we can do better than save at memory region fidelity which is at least
at page boundary if I am not wrong.
We can use type information to query and save the object's size without
including hundreds of unrelated ob
https://github.com/jeffreytan81 edited
https://github.com/llvm/llvm-project/pull/111601
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
https://github.com/jasonmolenda approved this pull request.
Thanks for the background here, I can see what a problem a function with
discontiguous ranges can be for some of our data structures. Looking at the
assembly in your test case (which is going to be really helpful if we try to
tackle
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
@@ -0,0 +1,31 @@
+#extend lldb::SBSaveCoreOptions {
+#ifdef SWIGPYTHON
+%pythoncode% {
+'''Add a thread to the SaveCoreOptions thread list, and follow it's
children N pointers deep, adding each memory region to the SaveCoreOptions
Memory region list.'''
+def
dwblaikie wrote:
Yeah, I think given how wide the change is and the speculative nature of the
harm - probably best to abandon this for now. We can pick it up again if more
folks speak up/more evidence is presented that it's problematic.
https://github.com/llvm/llvm-project/pull/110692
https://github.com/walter-erquinigo approved this pull request.
https://github.com/llvm/llvm-project/pull/104589
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DmT021 wrote:
> Was the setting intended for testing purposes only, or did you intend to
> include that in a final PR?
The latter. IMO the risks involved by parallelization are a bit too high to do
it without a flag. I'm even thinking about having it opt-in rather than opt-out
for some time.
Author: David Spickett
Date: 2024-10-08T09:36:56Z
New Revision: 39cdfdfad961e146131966757d563bfd667246d6
URL:
https://github.com/llvm/llvm-project/commit/39cdfdfad961e146131966757d563bfd667246d6
DIFF:
https://github.com/llvm/llvm-project/commit/39cdfdfad961e146131966757d563bfd667246d6.diff
LOG
99 matches
Mail list logo
