* [RFC] Removing in process agent (IPA) @ 2024-06-13 14:17 Andrew Burgess 2024-06-13 15:08 ` Luis Machado 0 siblings, 1 reply; 11+ messages in thread From: Andrew Burgess @ 2024-06-13 14:17 UTC (permalink / raw) To: gdb-patches, gdb Hi, I'd like to have a conversation about whether or not we want to keep the in-process-agent (IPA or libinproctrace.so). A couple of recent patches[1][2] have triggered the question of whether it would be better if we just dropped IPA from GDB. We do have some tests that make use of IPA in gdb.trace/, so its no untested code. I'd describe myself as neutral on this topic. I've never used the IPA myself, but I have no real objections to it continuing to live on. However, if nobody wants to keep it I'm happy to do to the work to remove it from GDB. So my question to the group: would anyone like to speak in favour of keeping the IPA around? Thanks, Andrew [1] https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com [2] https://inbox.sourceware.org/gdb-patches/f18d8f32e1e8af423e38efd0cb58ced1a98b5efb.1718271737.git.aburgess@redhat.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-13 14:17 [RFC] Removing in process agent (IPA) Andrew Burgess @ 2024-06-13 15:08 ` Luis Machado 2024-06-13 16:38 ` Tom Tromey 2024-06-13 18:11 ` Terekhov, Mikhail 0 siblings, 2 replies; 11+ messages in thread From: Luis Machado @ 2024-06-13 15:08 UTC (permalink / raw) To: Andrew Burgess, gdb-patches, gdb; +Cc: Pedro Alves On 6/13/24 15:17, Andrew Burgess via Gdb wrote: > > Hi, > > I'd like to have a conversation about whether or not we want to keep the > in-process-agent (IPA or libinproctrace.so). > > A couple of recent patches[1][2] have triggered the question of whether > it would be better if we just dropped IPA from GDB. > > We do have some tests that make use of IPA in gdb.trace/, so its no > untested code. > > I'd describe myself as neutral on this topic. I've never used the IPA > myself, but I have no real objections to it continuing to live on. > However, if nobody wants to keep it I'm happy to do to the work to > remove it from GDB. > > So my question to the group: would anyone like to speak in favour of > keeping the IPA around? > > Thanks, > Andrew > > [1] https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com > [2] https://inbox.sourceware.org/gdb-patches/f18d8f32e1e8af423e38efd0cb58ced1a98b5efb.1718271737.git.aburgess@redhat.com > Thanks for starting this Andrew. For context into this rather obscure (nowadays) library, [1] shows the original intended design and commit fa593d66d5696018bc8fb166f9e2a960d484ccd0 is the first pushed change to add the IPA, from what I could track down. [1] https://sourceware.org/legacy-ml/gdb/2011-12/msg00004.html [2] fa593d66d5696018bc8fb166f9e2a960d484ccd0 I think some of the design bits never made it into upstream gdb (itsets?), and the tracepoints mechanism was mostly used by non-gdbserver debugging servers, with gdbserver seemingly being more of a reference implementation. Fast-forward to today, we have a lot of multi-core/multi-threaded systems (even heterogeneous), but I can't really say the IPA library is being used more (or at all), or the way it was intended back in the day. We do use little bits (agent expressions), but not a lot. Nowadays we also have better debugging tools to do the job, not necessarily in gdb (RR, various tracing mechanisms). I think it is important to remove maintenance burden if possible, and with this perspective, I consider it is time for the IPA to go. 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. 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 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-13 15:08 ` Luis Machado @ 2024-06-13 16:38 ` Tom Tromey 2024-06-13 18:11 ` Terekhov, Mikhail 1 sibling, 0 replies; 11+ messages in thread From: Tom Tromey @ 2024-06-13 16:38 UTC (permalink / raw) To: Luis Machado; +Cc: Andrew Burgess, gdb-patches, gdb, Pedro Alves >> I'd like to have a conversation about whether or not we want to keep the >> in-process-agent (IPA or libinproctrace.so). Maybe you should ask on gdb@. I personally have never used tracepoints or IPA. However, I'm not exactly in the target audience, either, since most of my debugging is on gdb itself. Luis> Similarly, I also think it might be time to consider dropping the tracepoints Luis> (mainly static and fast) machinery from gdbserver, as I suspect that is another Luis> mechanism that is not being used very often. Something I found out relatively recently is that agent expressions are useful for letting gdbserver evaluate (some) breakpoint conditions. This happens automatically, when possible, and greatly improves performance. So, while I don't really mind either way about tracepoints, if we do remove these we should be careful to keep this part. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFC] Removing in process agent (IPA) 2024-06-13 15:08 ` Luis Machado 2024-06-13 16:38 ` Tom Tromey @ 2024-06-13 18:11 ` Terekhov, Mikhail 2024-06-14 7:54 ` Luis Machado 2024-06-14 8:08 ` Andrew Burgess 1 sibling, 2 replies; 11+ messages in thread From: Terekhov, Mikhail @ 2024-06-13 18:11 UTC (permalink / raw) To: Luis Machado, gdb-patches, gdb; +Cc: Pedro Alves, Andrew Burgess > -----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. Regards, Mikhail Internal Use - Confidential ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-13 18:11 ` Terekhov, Mikhail @ 2024-06-14 7:54 ` Luis Machado 2024-06-14 13:47 ` Terekhov, Mikhail 2024-06-14 8:08 ` Andrew Burgess 1 sibling, 1 reply; 11+ messages in thread From: Luis Machado @ 2024-06-14 7:54 UTC (permalink / raw) To: Terekhov, Mikhail, gdb-patches, gdb; +Cc: Pedro Alves, Andrew Burgess Hi Mikhail, Thanks for the input. On 6/13/24 19:11, Terekhov, Mikhail wrote: >> -----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. Is it a custom remote debugging stub that uses tracepoints through the RSP packets gdb sends? As opposed to using tracepoints through gdbserver itself? > >> 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.> > Regards, > Mikhail > > Internal Use - Confidential ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFC] Removing in process agent (IPA) 2024-06-14 7:54 ` Luis Machado @ 2024-06-14 13:47 ` Terekhov, Mikhail 0 siblings, 0 replies; 11+ messages in thread From: Terekhov, Mikhail @ 2024-06-14 13:47 UTC (permalink / raw) To: Luis Machado, gdb-patches, gdb; +Cc: Pedro Alves, Andrew Burgess > -----Original Message----- > From: Luis Machado <luis.machado@arm.com> Internal Use - Confidential > On 6/13/24 19:11, Terekhov, Mikhail wrote: > >> -----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. > > Is it a custom remote debugging stub that uses tracepoints through the RSP > packets gdb sends? As opposed to using tracepoints through gdbserver itself? > Both ways. No opposition😊 Regards, Mikhail ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFC] Removing in process agent (IPA) 2024-06-13 18:11 ` Terekhov, Mikhail 2024-06-14 7:54 ` Luis Machado @ 2024-06-14 8:08 ` Andrew Burgess 2024-06-14 13:42 ` Terekhov, Mikhail 2024-06-14 13:48 ` Simon Marchi 1 sibling, 2 replies; 11+ messages in thread From: Andrew Burgess @ 2024-06-14 8:08 UTC (permalink / raw) To: Terekhov, Mikhail, Luis Machado, gdb-patches, gdb; +Cc: Pedro Alves "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? Thanks, Andrew ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [RFC] Removing in process agent (IPA) 2024-06-14 8:08 ` Andrew Burgess @ 2024-06-14 13:42 ` Terekhov, Mikhail 2024-06-14 13:48 ` Simon Marchi 1 sibling, 0 replies; 11+ messages in thread From: Terekhov, Mikhail @ 2024-06-14 13:42 UTC (permalink / raw) To: Andrew Burgess, Luis Machado, gdb-patches, gdb; +Cc: Pedro Alves Internal Use - Confidential > -----Original Message----- > From: Andrew Burgess <aburgess@redhat.com> > Sent: Friday, June 14, 2024 4:08 AM > To: Terekhov, Mikhail <Mikhail.Terekhov@dell.com>; Luis Machado > <luis.machado@arm.com>; gdb-patches@sourceware.org; > gdb@sourceware.org > Cc: Pedro Alves <pedro@palves.net> > Subject: RE: [RFC] Removing in process agent (IPA) > > > [EXTERNAL EMAIL] > > "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? > Yes, you are right, I'm talking about GDB, remote protocol and stub. May be gdbserver in the future. > This doesn't require gdb to continue shipping the IPA right? Or have I failed to > understand your position? > We do not use IPA explicitly and I did not check if it's code is used in the tracepoints implementation. My replay was to the proposal to drop tracepoints. Regards, Mikhail ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-14 8:08 ` Andrew Burgess 2024-06-14 13:42 ` Terekhov, Mikhail @ 2024-06-14 13:48 ` Simon Marchi 2024-06-14 13:59 ` Luis Machado 1 sibling, 1 reply; 11+ messages in thread From: Simon Marchi @ 2024-06-14 13:48 UTC (permalink / raw) To: Andrew Burgess, Terekhov, Mikhail, Luis Machado, gdb-patches, gdb Cc: Pedro Alves 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). Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-14 13:48 ` Simon Marchi @ 2024-06-14 13:59 ` Luis Machado 2024-06-15 10:28 ` Andrew Burgess 0 siblings, 1 reply; 11+ messages in thread From: Luis Machado @ 2024-06-14 13:59 UTC (permalink / raw) To: Simon Marchi, Andrew Burgess, Terekhov, Mikhail, gdb-patches, gdb Cc: Pedro Alves 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Removing in process agent (IPA) 2024-06-14 13:59 ` Luis Machado @ 2024-06-15 10:28 ` Andrew Burgess 0 siblings, 0 replies; 11+ messages in thread From: Andrew Burgess @ 2024-06-15 10:28 UTC (permalink / raw) To: Luis Machado, Simon Marchi, Terekhov, Mikhail, gdb-patches, gdb Cc: Pedro Alves Luis Machado <luis.machado@arm.com> writes: > 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. While there are users of (3) I would suggest we should keep (2) so that we (GDB project) can test (3). My initial question was only about (1), dropping IPA and everything that implies. Again, I have no strong feelings either way, I asked only because the idea was floated in some replies in other threads and I thought the question should be asked in its own thread. Thanks, Andrew ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-06-15 10:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-13 14:17 [RFC] Removing in process agent (IPA) Andrew Burgess 2024-06-13 15:08 ` Luis Machado 2024-06-13 16:38 ` Tom Tromey 2024-06-13 18:11 ` Terekhov, Mikhail 2024-06-14 7:54 ` Luis Machado 2024-06-14 13:47 ` Terekhov, Mikhail 2024-06-14 8:08 ` Andrew Burgess 2024-06-14 13:42 ` Terekhov, Mikhail 2024-06-14 13:48 ` Simon Marchi 2024-06-14 13:59 ` Luis Machado 2024-06-15 10:28 ` Andrew Burgess
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).