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 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
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
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
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.
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
jimingham wrote:
I don't think there's a lot of reason to support registering lists of lldb
commands for the event, just having a python callback should be enough. I
think it's better to just do a scripted callback, and then have some command
that lets you add callbacks by module & class name
clayborg wrote:
I have wanted to be able to hook into target creation to be able to setup
targets when they get created. It would be also nice to get an event when a
process is not longer being debugged due to process exit or detach.
https://github.com/llvm/llvm-project/pull/111206
___
clayborg wrote:
> @jimingham , @clayborg, do you guys prefer `target stop-hook` style approach
> or `SBNotificationCallback` style python API callback?
>
> @clayborg, for `SBNotificationCallback`, does `lldb::SBExecutionContext` wrap
> the process, target or debugger object that is creating/de
jeffreytan81 wrote:
@jimingham , @clayborg, do you guys prefer `target stop-hook` style approach or
`SBNotificationCallback` style python API callback?
@clayborg, for `SBNotificationCallback`, does `lldb::SBExecutionContext` wrap
the process, target or debugger object that is creating/destro
jeffreytan81 wrote:
> Also, if you are going to hook creation, you should also hook destruction,
> shouldn't you? Whatever accounting you are doing for a debugger's once it
> exists might need to be torn down when that debugger goes away.
Right, `SBDebugger::AddDestroyCallback()` already exist
https://github.com/clayborg commented:
As Jim was saying, we might be able to make something a bit more useful so that
we can easily extend for other notifications of a debug session lifetime. Maybe
instead of:
```
typedef void (*SBDebuggerCreateCallback)(lldb::SBDebugger &debugger, void
*bato
jimingham wrote:
Also, if you are going to hook creation, you should also hook destruction,
shouldn't you? Whatever accounting you are doing for a debugger's once it
exists might need to be torn down when that debugger goes away.
https://github.com/llvm/llvm-project/pull/111206
__
jimingham wrote:
I'm of two minds about this. OTOH, it is certainly useful to be able to
observe Debugger creation. OTOH, it would be equally useful to be able to
observe Target creation and Process creation and probably other "debugger
lifecycle" events.
One of the tasks I've not had time
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
828783177f71d95522763fba92ef1e42dc6101c7...4f119961f3ae2d7bc40a2c00e18ee5774254c773
lldb/
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jeffreytan81)
Changes
This PR adds new SBDebugger::AddCreateCallback()/RemoveCreateCallback() APIs.
This API enables any lldb client to subscribe to debugger creation and perform
action on it. For example, we have telemetry code that
https://github.com/jeffreytan81 ready_for_review
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
https://github.com/jeffreytan81 created
https://github.com/llvm/llvm-project/pull/111206
This PR adds new SBDebugger::AddCreateCallback()/RemoveCreateCallback() APIs.
This API enables any lldb client to subscribe to debugger creation and perform
action on it. For example, we have telemetry cod
19 matches
Mail list logo
