public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line
@ 2011-07-19 18:13 Paul Pluzhnikov
  2011-07-19 18:44 ` Pedro Alves
  0 siblings, 1 reply; 4+ messages in thread
From: Paul Pluzhnikov @ 2011-07-19 18:13 UTC (permalink / raw)
  To: gdb-patches; +Cc: ppluzhnikov

Greetings,

Following up on my earlier "slow on high-latency links" message:
http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ...

Another source of major slowness for me is the gdbserver querying for
tracepoint symbols.

I see repeated (for each SOLIB) sequences of:

00:00:44 Sending packet: $qSymbol::#5b...Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
00:00:44 Packet qSymbol (symbol-lookup) is supported
00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f627566666572
00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f627566666572#e1...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64
00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64#ec...Packet received: qSymbol:6764625f6167656e745f636f6c6c656374696e67
00:00:44 Sending packet: $qSymbol::6764625f6167656e745f636f6c6c656374696e67#02...Packet received: qSymbol:6764625f6167656e745f6764625f636f6c6c656374
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f6764625f636f6c6c656374#65...Packet received: qSymbol:6764625f6167656e745f73746f705f74726163696e67
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f73746f705f74726163696e67#a3...Packet received: qSymbol:6764625f6167656e745f666c7573685f74726163655f627566666572
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f666c7573685f74726163655f627566666572#23...Packet received: qSymbol:6764625f6167656e745f61626f75745f746f5f726571756573745f6275666665725f7370616365
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f61626f75745f746f5f726571756573745f6275666665725f7370616365#3e...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f69735f66756c6c
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f69735f66756c6c#58...Packet received: qSymbol:6764625f6167656e745f73746f7070696e675f7472616365706f696e74
00:00:45 Sending packet: $qSymbol::6764625f6167656e745f73746f7070696e675f7472616365706f696e74#ed...Packet received: qSymbol:6764625f6167656e745f657870725f6576616c5f726573756c74
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f657870725f6576616c5f726573756c74#7b...Packet received: qSymbol:6764625f6167656e745f6572726f725f7472616365706f696e74
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f6572726f725f7472616365706f696e74#79...Packet received: qSymbol:6764625f6167656e745f7472616365706f696e7473
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f7472616365706f696e7473#06...Packet received: qSymbol:6764625f6167656e745f74726163696e67
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163696e67#30...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6374726c
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6374726c#b0...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6374726c5f63757272
00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6374726c5f63757272#f2...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6c6f
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6c6f#0f...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6869
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6869#b7...Packet received: qSymbol:6764625f6167656e745f74726163656672616d655f726561645f636f756e74
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d655f726561645f636f756e74#b7...Packet received: qSymbol:6764625f6167656e745f74726163656672616d655f77726974655f636f756e74
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d655f77726974655f636f756e74#2e...Packet received: qSymbol:6764625f6167656e745f74726163656672616d65735f63726561746564
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d65735f63726561746564#4e...Packet received: qSymbol:6764625f6167656e745f74726163655f73746174655f7661726961626c6573
00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f73746174655f7661726961626c6573#55...Packet received: qSymbol:6764625f6167656e745f6765745f7261775f726567
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f6765745f7261775f726567#0d...Packet received: qSymbol:6764625f6167656e745f6765745f74726163655f73746174655f7661726961626c655f76616c7565
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f6765745f74726163655f73746174655f7661726961626c655f76616c7565#a8...Packet received: qSymbol:6764625f6167656e745f7365745f74726163655f73746174655f7661726961626c655f76616c7565
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f7365745f74726163655f73746174655f7661726961626c655f76616c7565#a5...Packet received: qSymbol:6764625f6167656e745f7573745f6c6f61646564
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f7573745f6c6f61646564#cc...Packet received: qSymbol:6764625f6167656e745f68656c7065725f7468726561645f6964
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f68656c7065725f7468726561645f6964#4f...Packet received: qSymbol:6764625f6167656e745f636d645f627566
00:00:48 Sending packet: $qSymbol::6764625f6167656e745f636d645f627566#5d...Packet received: qSymbol:6e70746c5f76657273696f6e
00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: qSymbol:6e70746c5f76657273696f6e
00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: qSymbol:6e70746c5f76657273696f6e
00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: OK

Since I have 10 shared libraries in that executable, this costs me about
1 minute delay, and is completely wasted, because I am not going to use
tracepoints.

Attached patch allows me to disable tracepoint support via
--disable-tracepoints command line flag.

The patch would need documentation update, which I'll provide if the idea
of turning off tracepoints like that is not found too repulsive.

Thanks,
--
Paul Pluzhnikov


2011-07-19  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* server.c (disable_tracepoints): New variable.
	(support_tracepoints_p): New function.
	(handle_general_set, handle_query): Use it.
	(main): Handle --disable-tracepoints.


Index: gdbserver/server.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.c,v
retrieving revision 1.145
diff -u -p -r1.145 server.c
--- gdbserver/server.c	12 May 2011 12:09:17 -0000	1.145
+++ gdbserver/server.c	15 Jul 2011 22:54:42 -0000
@@ -92,6 +92,9 @@ int disable_packet_Tthread;
 int disable_packet_qC;
 int disable_packet_qfThreadInfo;
 
+/* Set if you want to disable tracepoints.  */
+int disable_tracepoints;
+
 /* Last status reported to GDB.  */
 static struct target_waitstatus last_status;
 static ptid_t last_ptid;
@@ -117,6 +120,14 @@ struct vstop_notif
 /* The pending stop replies list head.  */
 static struct vstop_notif *notif_queue = NULL;
 
+/* Do we support tracepoints.  */
+
+static int
+support_tracepoints_p ()
+{
+  return !disable_tracepoints && target_supports_tracepoints ();
+}
+
 /* Put a stop reply to the stop reply queue.  */
 
 static void
@@ -498,8 +509,7 @@ handle_general_set (char *own_buf)
       return;
     }
 
-  if (target_supports_tracepoints ()
-      && handle_tracepoint_general_set (own_buf))
+  if (support_tracepoints_p () && handle_tracepoint_general_set (own_buf))
     return;
 
   /* Otherwise we didn't know what packet it was.  Say we didn't
@@ -1378,7 +1388,7 @@ handle_query (char *own_buf, int packet_
 	 we access breakpoint shadows.  */
       validate_breakpoints ();
 
-      if (target_supports_tracepoints ())
+      if (support_tracepoints_p ())
 	tracepoint_look_up_symbols ();
 
       if (target_running () && the_target->look_up_symbols != NULL)
@@ -1529,7 +1539,7 @@ handle_query (char *own_buf, int packet_
 
       strcat (own_buf, ";qXfer:threads:read+");
 
-      if (target_supports_tracepoints ())
+      if (support_tracepoints_p ())
 	{
 	  strcat (own_buf, ";ConditionalTracepoints+");
 	  strcat (own_buf, ";TraceStateVariables+");
@@ -1730,7 +1740,7 @@ handle_query (char *own_buf, int packet_
   if (handle_qxfer (own_buf, packet_len, new_packet_len_p))
     return;
 
-  if (target_supports_tracepoints () && handle_tracepoint_query (own_buf))
+  if (support_tracepoints_p () && handle_tracepoint_query (own_buf))
     return;
 
   /* Otherwise we didn't know what packet it was.  Say we didn't
@@ -2533,6 +2543,8 @@ main (int argc, char *argv[])
 	}
       else if (strcmp (*next_arg, "--once") == 0)
 	run_once = 1;
+      else if (strcmp (*next_arg, "--disable-tracepoints") == 0)
+	disable_tracepoints = 1;
       else
 	{
 	  fprintf (stderr, "Unknown argument: %s\n", *next_arg);
@@ -2585,7 +2597,7 @@ main (int argc, char *argv[])
   initialize_inferiors ();
   initialize_async_io ();
   initialize_low ();
-  if (target_supports_tracepoints ())
+  if (support_tracepoints_p ())
     initialize_tracepoint ();
 
   own_buf = xmalloc (PBUFSIZ + 1);

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line
  2011-07-19 18:13 [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line Paul Pluzhnikov
@ 2011-07-19 18:44 ` Pedro Alves
  2011-07-19 20:31   ` Paul Pluzhnikov
  0 siblings, 1 reply; 4+ messages in thread
From: Pedro Alves @ 2011-07-19 18:44 UTC (permalink / raw)
  To: gdb-patches; +Cc: Paul Pluzhnikov

On Tuesday 19 July 2011 18:44:27, Paul Pluzhnikov wrote:
> Greetings,
> 
> Following up on my earlier "slow on high-latency links" message:
> http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ...
> 
> Another source of major slowness for me is the gdbserver querying for
> tracepoint symbols.
> 
> I see repeated (for each SOLIB) sequences of:
> 
> 00:00:44 Sending packet: $qSymbol::#5b...Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
> 00:00:44 Packet qSymbol (symbol-lookup) is supported
> 00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f627566666572
> 00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f627566666572#e1...Packet received: qSymbol:6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64
> 00:00:44 Sending packet: $qSymbol::6764625f6167656e745f6764625f6a756d705f7061645f6275666665725f656e64#ec...Packet received: qSymbol:6764625f6167656e745f636f6c6c656374696e67
> 00:00:44 Sending packet: $qSymbol::6764625f6167656e745f636f6c6c656374696e67#02...Packet received: qSymbol:6764625f6167656e745f6764625f636f6c6c656374
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f6764625f636f6c6c656374#65...Packet received: qSymbol:6764625f6167656e745f73746f705f74726163696e67
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f73746f705f74726163696e67#a3...Packet received: qSymbol:6764625f6167656e745f666c7573685f74726163655f627566666572
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f666c7573685f74726163655f627566666572#23...Packet received: qSymbol:6764625f6167656e745f61626f75745f746f5f726571756573745f6275666665725f7370616365
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f61626f75745f746f5f726571756573745f6275666665725f7370616365#3e...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f69735f66756c6c
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f69735f66756c6c#58...Packet received: qSymbol:6764625f6167656e745f73746f7070696e675f7472616365706f696e74
> 00:00:45 Sending packet: $qSymbol::6764625f6167656e745f73746f7070696e675f7472616365706f696e74#ed...Packet received: qSymbol:6764625f6167656e745f657870725f6576616c5f726573756c74
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f657870725f6576616c5f726573756c74#7b...Packet received: qSymbol:6764625f6167656e745f6572726f725f7472616365706f696e74
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f6572726f725f7472616365706f696e74#79...Packet received: qSymbol:6764625f6167656e745f7472616365706f696e7473
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f7472616365706f696e7473#06...Packet received: qSymbol:6764625f6167656e745f74726163696e67
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163696e67#30...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6374726c
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6374726c#b0...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6374726c5f63757272
> 00:00:46 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6374726c5f63757272#f2...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6c6f
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6c6f#0f...Packet received: qSymbol:6764625f6167656e745f74726163655f6275666665725f6869
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f6275666665725f6869#b7...Packet received: qSymbol:6764625f6167656e745f74726163656672616d655f726561645f636f756e74
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d655f726561645f636f756e74#b7...Packet received: qSymbol:6764625f6167656e745f74726163656672616d655f77726974655f636f756e74
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d655f77726974655f636f756e74#2e...Packet received: qSymbol:6764625f6167656e745f74726163656672616d65735f63726561746564
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163656672616d65735f63726561746564#4e...Packet received: qSymbol:6764625f6167656e745f74726163655f73746174655f7661726961626c6573
> 00:00:47 Sending packet: $qSymbol::6764625f6167656e745f74726163655f73746174655f7661726961626c6573#55...Packet received: qSymbol:6764625f6167656e745f6765745f7261775f726567
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f6765745f7261775f726567#0d...Packet received: qSymbol:6764625f6167656e745f6765745f74726163655f73746174655f7661726961626c655f76616c7565
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f6765745f74726163655f73746174655f7661726961626c655f76616c7565#a8...Packet received: qSymbol:6764625f6167656e745f7365745f74726163655f73746174655f7661726961626c655f76616c7565
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f7365745f74726163655f73746174655f7661726961626c655f76616c7565#a5...Packet received: qSymbol:6764625f6167656e745f7573745f6c6f61646564
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f7573745f6c6f61646564#cc...Packet received: qSymbol:6764625f6167656e745f68656c7065725f7468726561645f6964
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f68656c7065725f7468726561645f6964#4f...Packet received: qSymbol:6764625f6167656e745f636d645f627566
> 00:00:48 Sending packet: $qSymbol::6764625f6167656e745f636d645f627566#5d...Packet received: qSymbol:6e70746c5f76657273696f6e
> 00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: qSymbol:6e70746c5f76657273696f6e
> 00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: qSymbol:6e70746c5f76657273696f6e
> 00:00:49 Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d...Packet received: OK
> 
> Since I have 10 shared libraries in that executable, this costs me about
> 1 minute delay, and is completely wasted, because I am not going to use
> tracepoints.

Most of that querying is actually unnecessary.  All the symbols the
tracepoints module is looking up are required for libinproctrace.so to be
active.  So, there's no need to look them all up if any fails to be found, since
if any fails, we know we don't have libinproctrace.so loaded yet.  In practice,
we end up doing one (tracepoint related) query per DSO only.  Can you give the
patch below a try?  We have had this in our tree for months.  Hopefuly it'll
still apply cleanly.

-- 
Pedro Alves

2011-01-27  Pedro Alves  <pedro@codesourcery.com>

	gdb/gdbserver
	* gdbserver (tracepoint_look_up_symbols): Return upon the
	first symbol error.

Index: gdb/gdbserver/tracepoint.c
===================================================================
--- gdb.orig/gdbserver/tracepoint.c	2011-01-26 15:52:39.634522000 -0200
+++ gdb/gdbserver/tracepoint.c	2011-01-26 16:14:59.554522000 -0200
@@ -320,13 +320,11 @@
 void
 tracepoint_look_up_symbols (void)
 {
-  int all_ok;
   int i;
 
   if (all_tracepoint_symbols_looked_up)
     return;
 
-  all_ok = 1;
   for (i = 0; i < sizeof (symbol_list) / sizeof (symbol_list[0]); i++)
     {
       CORE_ADDR *addrp =
@@ -336,11 +334,11 @@
 	{
 	  if (debug_threads)
 	    fprintf (stderr, "symbol `%s' not found\n", symbol_list[i].name);
-	  all_ok = 0;
+	  return;
 	}
     }
 
-  all_tracepoint_symbols_looked_up = all_ok;
+  all_tracepoint_symbols_looked_up = 1;
 }
 
 #endif

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line
  2011-07-19 18:44 ` Pedro Alves
@ 2011-07-19 20:31   ` Paul Pluzhnikov
  2011-07-20 12:34     ` Pedro Alves
  0 siblings, 1 reply; 4+ messages in thread
From: Paul Pluzhnikov @ 2011-07-19 20:31 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

On Tue, Jul 19, 2011 at 11:28 AM, Pedro Alves <pedro@codesourcery.com> wrote:

> Most of that querying is actually unnecessary.  All the symbols the
> tracepoints module is looking up are required for libinproctrace.so to be
> active.  So, there's no need to look them all up if any fails to be found, since
> if any fails, we know we don't have libinproctrace.so loaded yet.  In practice,
> we end up doing one (tracepoint related) query per DSO only.  Can you give the
> patch below a try?  We have had this in our tree for months.  Hopefuly it'll
> still apply cleanly.

It does apply cleanly, and does reduce the number of packets from
28*10 to just 10.

Could you commit it?

Thanks,
-- 
Paul Pluzhnikov

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line
  2011-07-19 20:31   ` Paul Pluzhnikov
@ 2011-07-20 12:34     ` Pedro Alves
  0 siblings, 0 replies; 4+ messages in thread
From: Pedro Alves @ 2011-07-20 12:34 UTC (permalink / raw)
  To: Paul Pluzhnikov; +Cc: gdb-patches

On Tuesday 19 July 2011 21:27:04, Paul Pluzhnikov wrote:
> On Tue, Jul 19, 2011 at 11:28 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> 
> > Most of that querying is actually unnecessary.  All the symbols the
> > tracepoints module is looking up are required for libinproctrace.so to be
> > active.  So, there's no need to look them all up if any fails to be found, since
> > if any fails, we know we don't have libinproctrace.so loaded yet.  In practice,
> > we end up doing one (tracepoint related) query per DSO only.  Can you give the
> > patch below a try?  We have had this in our tree for months.  Hopefuly it'll
> > still apply cleanly.
> 
> It does apply cleanly, and does reduce the number of packets from
> 28*10 to just 10.
> 
> Could you commit it?

Done.

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-07-20 11:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-19 18:13 [RFC][patch] Allow user to disable tracepoint support in gdbserver via command line Paul Pluzhnikov
2011-07-19 18:44 ` Pedro Alves
2011-07-19 20:31   ` Paul Pluzhnikov
2011-07-20 12:34     ` Pedro Alves

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).