Re: [RFC] Removing in process agent (IPA)

[Luis Machado <luis.machado@arm.com>]

On 6/14/24 14:48, Simon Marchi wrote:
> 
> 
> On 2024-06-14 04:08, Andrew Burgess wrote:
>> "Terekhov, Mikhail" <Mikhail.Terekhov@dell.com> writes:
>>
>>>> -----Original Message-----
>>>> From: Luis Machado <luis.machado@arm.com>
>>>>
>>>> Similarly, I also think it might be time to consider dropping the tracepoints
>>>> (mainly static and fast) machinery from gdbserver, as I suspect that is another
>>>> mechanism that is not being used very often.
>>>>
>>> We use tracepoints in our stub from the last millennia I guess (back from EMC days)
>>> and plan to do so in the future.
>>>
>>>> I recall trying to use tracepoints for practical purposes (back in the day), and it
>>>> wasn't up to the task, being too cumbersome to use, having bad failure modes
>>>
>>> Putting some UI/GUI on top of it makes it relatively simple to use.
>>>
>>>> and having other security implications when trying to debug stuff in
>>>> production platforms. The remote protocol side of it is OK, but again, I bet no
>>>> debugging stubs are using that anymore.
>>>
>>> We do use them but not in production though.
>>
>> Just so I'm clear, you're talking about tracepoints here either in
>> gdbserver, or at least (if you have your own stub) in GDB and the remote
>> protocol, right?
>>
>> This doesn't require gdb to continue shipping the IPA right?  Or have I
>> failed to understand your position?
> 
> Just to clarify one thing: the IPA is only needed for the fast
> tracepoints mechanism, which allows recording trace data all in process,
> without hitting a trap and the control going back to GDBserver.  We can
> still use regular trap-based tracepoints without the IPA.
> 
> The possible levels of removal are:
> 
> 1. Remove the IPA, thus removing the support for fast tracepoints in
>    GDBserver (you could still use regular trap-based tracepoints)
> 2. Remove the support for tracepoints in GDBserver altogether (you could
>    still use the tracepoints feature in GDB, when connecting to another
>    RSP implementation than GDBserver, although the tracepoints feature
>    in GDB would become untested code)
> 3. Remove the support for tracepoints in GDB and GDBserver completely
>    (which I would not consider since Mikhail says they use that).

To be clear, I'm only proposing removing (1) at the moment. (2) might be worth
removing in the future if nobody is still using it (drops tracepoint support in
gdbserver). (3) is the more generic layer, and I suppose there are still a few
users out there.