Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* RDI code busy-waiting on running target?
@ 2002-07-11 15:55 Grant Edwards
  2002-07-11 16:40 ` Grant Edwards
  0 siblings, 1 reply; 7+ messages in thread
From: Grant Edwards @ 2002-07-11 15:55 UTC (permalink / raw)
  To: gdb


[gdb 5.1.1, rdi target]

I've noticed that gdb uses all the CPU it can get while the
target is running (e.g. busy-waiting 'till target stops).

I'm building 5.2 to see if it still does that, but the build is
taking forever since I'm also testing some ARM code and gdb
5.1.1 is using 50% of the CPU waiting for the target to stop.  :)

Anybody else seen this?

-- 
Grant Edwards
grante@visi.com


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

* Re: RDI code busy-waiting on running target?
  2002-07-11 15:55 RDI code busy-waiting on running target? Grant Edwards
@ 2002-07-11 16:40 ` Grant Edwards
  2002-07-11 16:53   ` Keith Seitz
  2002-07-12  8:23   ` Grant Edwards
  0 siblings, 2 replies; 7+ messages in thread
From: Grant Edwards @ 2002-07-11 16:40 UTC (permalink / raw)
  To: gdb; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Thu, Jul 11, 2002 at 05:58:56PM -0500, Grant Edwards wrote:

> I've noticed that gdb uses all the CPU it can get while the
> target is running (e.g. busy-waiting 'till target stops).
> 
> I'm building 5.2 to see if it still does that

Yup.  

Here's a patch that fixes it.  I only added the usleep() when
there's no ui_loop_hook to call.  Is that the right thing to
do, or will Insight et al still suck CPU time?  I'm not sure
who's supposed to be surrendering the CPU, the UI or the
target.

Is usleep() portable?

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1296 bytes --]

diff -r -U8 gdb-5.2/gdb/ChangeLog gdb-5.2-mod/gdb/ChangeLog
--- gdb-5.2/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2-mod/gdb/ChangeLog	Thu Jul 11 18:39:18 2002
@@ -1,8 +1,14 @@
+2002-09-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep (iff there's no
+          ui_loop_hook) to busy-wait loop when target is
+          running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
Only in gdb-5.2-mod/gdb: ChangeLog~
diff -r -U8 gdb-5.2/gdb/rdi-share/ardi.c gdb-5.2-mod/gdb/rdi-share/ardi.c
--- gdb-5.2/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2-mod/gdb/rdi-share/ardi.c	Thu Jul 11 18:28:58 2002
@@ -1411,16 +1411,18 @@
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
     if (ui_loop_hook)
       ui_loop_hook(0);
+    else
+      usleep(10000);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;
       }
     Adp_AsynchronousProcessing( async_block_on_nothing );

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

* Re: RDI code busy-waiting on running target?
  2002-07-11 16:40 ` Grant Edwards
@ 2002-07-11 16:53   ` Keith Seitz
  2002-07-11 17:28     ` Grant Edwards
  2002-07-12  8:23   ` Grant Edwards
  1 sibling, 1 reply; 7+ messages in thread
From: Keith Seitz @ 2002-07-11 16:53 UTC (permalink / raw)
  To: Grant Edwards; +Cc: gdb, gdb-patches

On Thu, 11 Jul 2002, Grant Edwards wrote:

> Here's a patch that fixes it.  I only added the usleep() when
> there's no ui_loop_hook to call.  Is that the right thing to
> do, or will Insight et al still suck CPU time?  I'm not sure
> who's supposed to be surrendering the CPU, the UI or the
> target.

Insight would definitely shoot to 100% CPU, too. This often a problem with
have gdb non-event based w.r.t. the target. I would recommend doing the
sleep for the ui_loop_hook, too.

Keith



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

* Re: RDI code busy-waiting on running target?
  2002-07-11 16:53   ` Keith Seitz
@ 2002-07-11 17:28     ` Grant Edwards
  0 siblings, 0 replies; 7+ messages in thread
From: Grant Edwards @ 2002-07-11 17:28 UTC (permalink / raw)
  To: gdb, gdb-patches

On Thu, Jul 11, 2002 at 04:53:39PM -0700, Keith Seitz wrote:
> On Thu, 11 Jul 2002, Grant Edwards wrote:
>
> > Here's a patch that fixes it.  I only added the usleep() when
> > there's no ui_loop_hook to call.  Is that the right thing to
> > do, or will Insight et al still suck CPU time?  I'm not sure
> > who's supposed to be surrendering the CPU, the UI or the
> > target.
> 
> Insight would definitely shoot to 100% CPU, too. This often a problem with
> have gdb non-event based w.r.t. the target. I would recommend doing the
> sleep for the ui_loop_hook, too.

I'll submit a replacement patch tomorrow.

-- 
Grant Edwards
grante@visi.com


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

* Re: RDI code busy-waiting on running target?
  2002-07-11 16:40 ` Grant Edwards
  2002-07-11 16:53   ` Keith Seitz
@ 2002-07-12  8:23   ` Grant Edwards
  2002-07-12 11:03     ` Grant Edwards
  1 sibling, 1 reply; 7+ messages in thread
From: Grant Edwards @ 2002-07-12  8:23 UTC (permalink / raw)
  To: gdb; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Thu, Jul 11, 2002 at 06:43:43PM -0500, Grant Edwards wrote:

> > I've noticed that gdb uses all the CPU it can get while the
> > target is running (e.g. busy-waiting 'till target stops).
>
> Here's a patch that fixes it.

Here's a new version of the patch that does the sleep
unconditionally and uses select() instead of usleep().

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1211 bytes --]

diff -r -U8 gdb-5.2-orig/gdb/ChangeLog gdb-5.2/gdb/ChangeLog
--- gdb-5.2-orig/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2/gdb/ChangeLog	Fri Jul 12 10:22:38 2002
@@ -1,8 +1,13 @@
+2002-07-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep to busy-wait loop
+        when target is running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
diff -r -U8 gdb-5.2-orig/gdb/rdi-share/ardi.c gdb-5.2/gdb/rdi-share/ardi.c
--- gdb-5.2-orig/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2/gdb/rdi-share/ardi.c	Fri Jul 12 10:17:37 2002
@@ -1409,16 +1409,20 @@
 #endif
 
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
+    struct timeval timeout = {0,10000};
+
+    select(0,0,0,0,&timeout);
+    
     if (ui_loop_hook)
       ui_loop_hook(0);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;

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

* Re: RDI code busy-waiting on running target?
  2002-07-12  8:23   ` Grant Edwards
@ 2002-07-12 11:03     ` Grant Edwards
  0 siblings, 0 replies; 7+ messages in thread
From: Grant Edwards @ 2002-07-12 11:03 UTC (permalink / raw)
  To: gdb; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Fri, Jul 12, 2002 at 10:26:53AM -0500, Grant Edwards wrote:
> > I've noticed that gdb uses all the CPU it can get while the
> > target is running (e.g. busy-waiting 'till target stops).
>
> Here's a patch that fixes it.

Thanks to Dan Kegel for pointing out that an auto struct with
initializer isn't kosher.  One more try...

-- 
Grant Edwards
grante@visi.com

[-- Attachment #2: rdi-busy-wait.patch --]
[-- Type: text/plain, Size: 1254 bytes --]

diff -r -U8 gdb-5.2-orig/gdb/ChangeLog gdb-5.2/gdb/ChangeLog
--- gdb-5.2-orig/gdb/ChangeLog	Fri Apr 26 20:05:21 2002
+++ gdb-5.2/gdb/ChangeLog	Fri Jul 12 10:22:38 2002
@@ -1,8 +1,13 @@
+2002-07-11  Grant Edwards <grante@visi.com>
+
+        * rdi-share/ardi.c: add 10ms sleep to busy-wait loop
+        when target is running.
+
 2002-04-26  GDB Administrator  <gdbadmin@sourceware.cygnus.com>
 
 	GDB 5.2 Released.
 	* version.in: Update to version 5.2.
 
 2002-04-26  Michal Ludvig  <mludvig@suse.cz>
 
 	* x86-64-tdep.c (x86_64_skip_prologue): Print note when debugging
diff -r -U8 gdb-5.2-orig/gdb/rdi-share/ardi.c gdb-5.2/gdb/rdi-share/ardi.c
--- gdb-5.2-orig/gdb/rdi-share/ardi.c	Thu Oct 12 17:56:31 2000
+++ gdb-5.2/gdb/rdi-share/ardi.c	Fri Jul 12 13:03:35 2002
@@ -1409,16 +1409,22 @@
 #endif
 
   interrupt_request = FALSE;
   stop_request = FALSE;
   
   signal(SIGINT, ardi_sigint_handler);
   while( executing )
   {
+    struct timeval timeout;
+    timeout.tv_sec = 0;
+    timeout.tv_usec = 10000;
+
+    select(0,0,0,0,&timeout);
+    
     if (ui_loop_hook)
       ui_loop_hook(0);
     
     if (interrupt_request || stop_request)
       {
         interrupt_target();
         interrupt_request = FALSE;
         stop_request = FALSE;

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

* RE: RDI code busy-waiting on running target?
@ 2002-07-11 17:44 Dan Kegel
  0 siblings, 0 replies; 7+ messages in thread
From: Dan Kegel @ 2002-07-11 17:44 UTC (permalink / raw)
  To: 'Grant Edwards ', 'gdb@sources.redhat.com '
  Cc: 'gdb-patches@sources.redhat.com '

Grant Edwards wrote:

> Is usleep() portable?

http://sarien.sourceforge.net/hackersguide/intro-portability.html
claims no.

It uses a timer on some platforms, too, so I'd avoid it anyway.

You might consider using select() with no fds to sleep briefly.  That's
tradition.

- Dan


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

end of thread, other threads:[~2002-07-12 18:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-11 15:55 RDI code busy-waiting on running target? Grant Edwards
2002-07-11 16:40 ` Grant Edwards
2002-07-11 16:53   ` Keith Seitz
2002-07-11 17:28     ` Grant Edwards
2002-07-12  8:23   ` Grant Edwards
2002-07-12 11:03     ` Grant Edwards
2002-07-11 17:44 Dan Kegel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox