[RFA/testsuite] attach.exp: Add small delay in busy loop...

[RFA/testsuite] attach.exp: Add small delay in busy loop...

[Joel Brobecker]

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

Hello,

The attach.exp sometimes fails on certain platforms (eg mips-irix),
and causes an attach process to be left behind. Since it is doing a busy
loop, this runaway process left behind consumes 99.9% of the CPU,
and considerably slows down the execution of the rest of the testsuite.

I suggest the following change to add a small delay at each iteration
of the busy loop. I had to make some adjustments to attach.exp:

  a. Line number 19 became line 32.
     Just like Elena recently upgraded a test to avoid hard-coded
     line number, we should probably clean this up, someday. This can
     be a separate patch, however.

  b. The program was attached to while inside the busy loop, so the
     test was expecting the debugger to report that the inferior was
     inside function main() after the attach command was performed.
     This is no longer the case, since the inferior is most likely
     inside a system call, doing the delay. I felt that it was not
     a necessity to checke where the debugger thought the inferior
     was stopped, so removed that part of the expected output. What
     I can do is add an extra test that does a backtrace and verifies
     that it contains a frame for function main().

2003-11-18  J. Brobecker  <brobecker@gnat.com>

        * gdb.base/attach.c: Add small delay in busy loop.
        * gdb.base/attach.exp: Make some associated adjustments.

OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: attach.diff --]
[-- Type: text/plain, Size: 3486 bytes --]

Index: attach.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 attach.c
--- attach.c	28 Jun 1999 23:02:40 -0000	1.1.1.1
+++ attach.c	18 Nov 2003 22:51:12 -0000
@@ -5,15 +5,28 @@
    exit unless/until gdb sets the variable to non-zero.)
    */
 #include <stdio.h>
+#include <time.h>
 
 int  should_exit = 0;
 
+/* Wait for 0.1 sec.  */
+
+void
+small_delay ()
+{
+  const struct timespec ts = { 0, 1000000 }; /* 0.1 sec */
+  nanosleep (&ts, NULL);
+}
+
 int main ()
 {
   int  local_i = 0;
 
   while (! should_exit)
     {
+      /* Insert a small delay in order to avoid consuming all the CPU
+         while waiting for the debugger to take control.  */
+      small_delay ();
       local_i++;
     }
   return 0;
Index: attach.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.exp,v
retrieving revision 1.12
diff -u -p -r1.12 attach.exp
--- attach.exp	7 Aug 2003 17:55:41 -0000	1.12
+++ attach.exp	18 Nov 2003 22:51:13 -0000
@@ -173,7 +173,7 @@ proc do_attach_tests {} {
 
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $"\
+      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*$gdb_prompt $"\
                       {pass "attach1, after setting file"}
       -re "$gdb_prompt $" {fail "attach1, after setting file"}
       timeout         {fail "(timeout) attach1, after setting file"}
@@ -236,7 +236,7 @@ proc do_attach_tests {} {
    #
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
+      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
                       {pass "attach2"}
       -re "$gdb_prompt $" {fail "attach2"}
       timeout         {fail "(timeout) attach2"}
@@ -253,16 +253,16 @@ proc do_attach_tests {} {
 
    # Verify that the modification really happened.
    #
-   send_gdb "tbreak 19\n"
+   send_gdb "tbreak 32\n"
    gdb_expect {
-      -re "Breakpoint .*at.*$srcfile, line 19.*$gdb_prompt $"\
+      -re "Breakpoint .*at.*$srcfile, line 32.*$gdb_prompt $"\
                       {pass "after attach2, set tbreak postloop"}
       -re "$gdb_prompt $" {fail "after attach2, set tbreak postloop"}
       timeout         {fail "(timeout) after attach2, set tbreak postloop"}
    }
    send_gdb "continue\n"
    gdb_expect {
-      -re "main.*at.*$srcfile:19.*$gdb_prompt $"\
+      -re "main.*at.*$srcfile:32.*$gdb_prompt $"\
                       {pass "after attach2, reach tbreak postloop"}
       -re "$gdb_prompt $" {fail "after attach2, reach tbreak postloop"}
       timeout         {fail "(timeout) after attach2, reach tbreak postloop"}
@@ -337,7 +337,7 @@ proc do_attach_tests {} {
 
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
+      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
                       {pass "attach when process' a.out not in cwd"}
       -re "$gdb_prompt $" {fail "attach when process' a.out not in cwd"}
       timeout         {fail "(timeout) attach when process' a.out not in cwd"}

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Michael Snyder]

Joel Brobecker wrote:
> Hello,
> 
> The attach.exp sometimes fails on certain platforms (eg mips-irix),
> and causes an attach process to be left behind. Since it is doing a busy
> loop, this runaway process left behind consumes 99.9% of the CPU,
> and considerably slows down the execution of the rest of the testsuite.
> 
> I suggest the following change to add a small delay at each iteration
> of the busy loop. I had to make some adjustments to attach.exp:
> 
>   a. Line number 19 became line 32.
>      Just like Elena recently upgraded a test to avoid hard-coded
>      line number, we should probably clean this up, someday. This can
>      be a separate patch, however.
> 
>   b. The program was attached to while inside the busy loop, so the
>      test was expecting the debugger to report that the inferior was
>      inside function main() after the attach command was performed.
>      This is no longer the case, since the inferior is most likely
>      inside a system call, doing the delay. I felt that it was not
>      a necessity to checke where the debugger thought the inferior
>      was stopped, so removed that part of the expected output. What
>      I can do is add an extra test that does a backtrace and verifies
>      that it contains a frame for function main().
> 
> 2003-11-18  J. Brobecker  <brobecker@gnat.com>
> 
>         * gdb.base/attach.c: Add small delay in busy loop.
>         * gdb.base/attach.exp: Make some associated adjustments.
> 
> OK to apply?

Seems to work on Linux.  I'd sure like to see that backtrace test,
though, to confirm that we are able to build a meaningful machine
state after we attach.

Michael

> ------------------------------------------------------------------------
> 
> Index: attach.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.c,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 attach.c
> --- attach.c	28 Jun 1999 23:02:40 -0000	1.1.1.1
> +++ attach.c	18 Nov 2003 22:51:12 -0000
> @@ -5,15 +5,28 @@
>     exit unless/until gdb sets the variable to non-zero.)
>     */
>  #include <stdio.h>
> +#include <time.h>
>  
>  int  should_exit = 0;
>  
> +/* Wait for 0.1 sec.  */
> +
> +void
> +small_delay ()
> +{
> +  const struct timespec ts = { 0, 1000000 }; /* 0.1 sec */
> +  nanosleep (&ts, NULL);
> +}
> +
>  int main ()
>  {
>    int  local_i = 0;
>  
>    while (! should_exit)
>      {
> +      /* Insert a small delay in order to avoid consuming all the CPU
> +         while waiting for the debugger to take control.  */
> +      small_delay ();
>        local_i++;
>      }
>    return 0;
> Index: attach.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.exp,v
> retrieving revision 1.12
> diff -u -p -r1.12 attach.exp
> --- attach.exp	7 Aug 2003 17:55:41 -0000	1.12
> +++ attach.exp	18 Nov 2003 22:51:13 -0000
> @@ -173,7 +173,7 @@ proc do_attach_tests {} {
>  
>     send_gdb "attach $testpid\n"
>     gdb_expect {
> -      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $"\
> +      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*$gdb_prompt $"\
>                        {pass "attach1, after setting file"}
>        -re "$gdb_prompt $" {fail "attach1, after setting file"}
>        timeout         {fail "(timeout) attach1, after setting file"}
> @@ -236,7 +236,7 @@ proc do_attach_tests {} {
>     #
>     send_gdb "attach $testpid\n"
>     gdb_expect {
> -      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
> +      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
>                        {pass "attach2"}
>        -re "$gdb_prompt $" {fail "attach2"}
>        timeout         {fail "(timeout) attach2"}
> @@ -253,16 +253,16 @@ proc do_attach_tests {} {
>  
>     # Verify that the modification really happened.
>     #
> -   send_gdb "tbreak 19\n"
> +   send_gdb "tbreak 32\n"
>     gdb_expect {
> -      -re "Breakpoint .*at.*$srcfile, line 19.*$gdb_prompt $"\
> +      -re "Breakpoint .*at.*$srcfile, line 32.*$gdb_prompt $"\
>                        {pass "after attach2, set tbreak postloop"}
>        -re "$gdb_prompt $" {fail "after attach2, set tbreak postloop"}
>        timeout         {fail "(timeout) after attach2, set tbreak postloop"}
>     }
>     send_gdb "continue\n"
>     gdb_expect {
> -      -re "main.*at.*$srcfile:19.*$gdb_prompt $"\
> +      -re "main.*at.*$srcfile:32.*$gdb_prompt $"\
>                        {pass "after attach2, reach tbreak postloop"}
>        -re "$gdb_prompt $" {fail "after attach2, reach tbreak postloop"}
>        timeout         {fail "(timeout) after attach2, reach tbreak postloop"}
> @@ -337,7 +337,7 @@ proc do_attach_tests {} {
>  
>     send_gdb "attach $testpid\n"
>     gdb_expect {
> -      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
> +      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
>                        {pass "attach when process' a.out not in cwd"}
>        -re "$gdb_prompt $" {fail "attach when process' a.out not in cwd"}
>        timeout         {fail "(timeout) attach when process' a.out not in cwd"}

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Daniel Jacobowitz]

On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:
> Joel Brobecker wrote:
> >Hello,
> >
> >The attach.exp sometimes fails on certain platforms (eg mips-irix),
> >and causes an attach process to be left behind. Since it is doing a busy
> >loop, this runaway process left behind consumes 99.9% of the CPU,
> >and considerably slows down the execution of the rest of the testsuite.
> >
> >I suggest the following change to add a small delay at each iteration
> >of the busy loop. I had to make some adjustments to attach.exp:
> >
> >  a. Line number 19 became line 32.
> >     Just like Elena recently upgraded a test to avoid hard-coded
> >     line number, we should probably clean this up, someday. This can
> >     be a separate patch, however.
> >
> >  b. The program was attached to while inside the busy loop, so the
> >     test was expecting the debugger to report that the inferior was
> >     inside function main() after the attach command was performed.
> >     This is no longer the case, since the inferior is most likely
> >     inside a system call, doing the delay. I felt that it was not
> >     a necessity to checke where the debugger thought the inferior
> >     was stopped, so removed that part of the expected output. What
> >     I can do is add an extra test that does a backtrace and verifies
> >     that it contains a frame for function main().
> >
> >2003-11-18  J. Brobecker  <brobecker@gnat.com>
> >
> >        * gdb.base/attach.c: Add small delay in busy loop.
> >        * gdb.base/attach.exp: Make some associated adjustments.
> >
> >OK to apply?
> 
> Seems to work on Linux.  I'd sure like to see that backtrace test,
> though, to confirm that we are able to build a meaningful machine
> state after we attach.

Seems reasonable to me.  Warning: this will be yet another place we
backtrace from syscalls, and sometimes we just can't do that.  We
already have a couple of configurations where GDB can't reasonably be
expected to backtrace out of nanosleep.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:
> 
>>Joel Brobecker wrote:
>>
>>>Hello,
>>>
>>>The attach.exp sometimes fails on certain platforms (eg mips-irix),
>>>and causes an attach process to be left behind. Since it is doing a busy
>>>loop, this runaway process left behind consumes 99.9% of the CPU,
>>>and considerably slows down the execution of the rest of the testsuite.
>>>
>>>I suggest the following change to add a small delay at each iteration
>>>of the busy loop. I had to make some adjustments to attach.exp:
>>>
>>> a. Line number 19 became line 32.
>>>    Just like Elena recently upgraded a test to avoid hard-coded
>>>    line number, we should probably clean this up, someday. This can
>>>    be a separate patch, however.
>>>
>>> b. The program was attached to while inside the busy loop, so the
>>>    test was expecting the debugger to report that the inferior was
>>>    inside function main() after the attach command was performed.
>>>    This is no longer the case, since the inferior is most likely
>>>    inside a system call, doing the delay. I felt that it was not
>>>    a necessity to checke where the debugger thought the inferior
>>>    was stopped, so removed that part of the expected output. What
>>>    I can do is add an extra test that does a backtrace and verifies
>>>    that it contains a frame for function main().
>>>
>>>2003-11-18  J. Brobecker  <brobecker@gnat.com>
>>>
>>>       * gdb.base/attach.c: Add small delay in busy loop.
>>>       * gdb.base/attach.exp: Make some associated adjustments.
>>>
>>>OK to apply?
>>
>>Seems to work on Linux.  I'd sure like to see that backtrace test,
>>though, to confirm that we are able to build a meaningful machine
>>state after we attach.
> 
> 
> Seems reasonable to me.  Warning: this will be yet another place we
> backtrace from syscalls, and sometimes we just can't do that.  We
> already have a couple of configurations where GDB can't reasonably be
> expected to backtrace out of nanosleep.

Well, we could run to a known breakpoint and then backtrace --
but that wouldn't test the state immediately after attach.
Can you think of a good test for a valid state, other than
a backtrace?

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Daniel Jacobowitz]

On Wed, Nov 19, 2003 at 11:15:55AM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:
> >
> >>Joel Brobecker wrote:
> >>
> >>>Hello,
> >>>
> >>>The attach.exp sometimes fails on certain platforms (eg mips-irix),
> >>>and causes an attach process to be left behind. Since it is doing a busy
> >>>loop, this runaway process left behind consumes 99.9% of the CPU,
> >>>and considerably slows down the execution of the rest of the testsuite.
> >>>
> >>>I suggest the following change to add a small delay at each iteration
> >>>of the busy loop. I had to make some adjustments to attach.exp:
> >>>
> >>>a. Line number 19 became line 32.
> >>>   Just like Elena recently upgraded a test to avoid hard-coded
> >>>   line number, we should probably clean this up, someday. This can
> >>>   be a separate patch, however.
> >>>
> >>>b. The program was attached to while inside the busy loop, so the
> >>>   test was expecting the debugger to report that the inferior was
> >>>   inside function main() after the attach command was performed.
> >>>   This is no longer the case, since the inferior is most likely
> >>>   inside a system call, doing the delay. I felt that it was not
> >>>   a necessity to checke where the debugger thought the inferior
> >>>   was stopped, so removed that part of the expected output. What
> >>>   I can do is add an extra test that does a backtrace and verifies
> >>>   that it contains a frame for function main().
> >>>
> >>>2003-11-18  J. Brobecker  <brobecker@gnat.com>
> >>>
> >>>      * gdb.base/attach.c: Add small delay in busy loop.
> >>>      * gdb.base/attach.exp: Make some associated adjustments.
> >>>
> >>>OK to apply?
> >>
> >>Seems to work on Linux.  I'd sure like to see that backtrace test,
> >>though, to confirm that we are able to build a meaningful machine
> >>state after we attach.
> >
> >
> >Seems reasonable to me.  Warning: this will be yet another place we
> >backtrace from syscalls, and sometimes we just can't do that.  We
> >already have a couple of configurations where GDB can't reasonably be
> >expected to backtrace out of nanosleep.
> 
> Well, we could run to a known breakpoint and then backtrace --
> but that wouldn't test the state immediately after attach.
> Can you think of a good test for a valid state, other than
> a backtrace?

Not really.  Let's not worry about the problem for now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Joel Brobecker]

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

Hello,

On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:
> >2003-11-18  J. Brobecker  <brobecker@gnat.com>
> >
> >        * gdb.base/attach.c: Add small delay in busy loop.
> >        * gdb.base/attach.exp: Make some associated adjustments.
> >
> >OK to apply?
> 
> Seems to work on Linux.  I'd sure like to see that backtrace test,
> though, to confirm that we are able to build a meaningful machine
> state after we attach.

Here is a new version of the patch, with the backtraces in. I do have
two FAILs though. The first FAIL comes from the following test:

   gdb_test "backtrace" \
            ".*in nanosleep ().*in small_delay ().*in main ().*" \
            "backtrace after attach2"

The logs show:

        backtrace
        #0  0x400eb3b5 in ?? () from /lib/libc.so.6
        #1  0x08048412 in small_delay () at ./gdb.base/attach.c:18
        #2  0x08048435 in main () at ./gdb.base/attach.c:29
        (gdb) FAIL: gdb.base/attach.exp: backtrace after attach2

So the problem is that GDB is unable to find the function name for
frame $0. I think this comes from these warnings while performing
the attach command:

        attach 3671
        Attaching to process 3671
        Reading symbols from /[...]/testsuite/gdb.base/attach...done.
  -->   Symbols already loaded for /lib/libm.so.6
  -->   Symbols already loaded for /lib/libc.so.6
        Symbols already loaded for /lib/ld-linux.so.2
        0x400eb3b5 in ?? () from /lib/libc.so.6^M 
        (gdb) PASS: gdb.base/attach.exp: attach2

The second FAIL is identical.

I am not sure what's best to do. Normally, the first purpose when I
wrote the test was to make sure that we were able to see a frame
for procedure main(), and then got overzealous by checking that we
could see at least main(), small_delay() and nanosleep(). But then
this problem came up. In my opinion, we should still keep my zealous
version of the expected output for the "backtrace" commands and either
leave with the fail, or make them as KFAILS (or whatever proper state
it should be, I didn't much follow that discussion).

There is another thing that I think needs mentioning. I noticed I am
the first one to introduce the use of nanosleep(). I think it's pretty
portable, but I am having doubts. Does anybody know if it's not available
on any platform. How about cygwin for instance?

Otherwise, is there another function that I could use instead? Sleep is
used in several of the tests - although the timer resolution is much
coarser, it would probably be fine to use sleep() in this test too.
There is also select, but I'm not sure it's available on cygwin. It's
already been used in one of the pthread examples, though...

-- 
Joel

[-- Attachment #2: attach.diff --]
[-- Type: text/plain, Size: 4187 bytes --]

Index: attach.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 attach.c
--- attach.c	28 Jun 1999 23:02:40 -0000	1.1.1.1
+++ attach.c	20 Nov 2003 06:17:45 -0000
@@ -5,15 +5,28 @@
    exit unless/until gdb sets the variable to non-zero.)
    */
 #include <stdio.h>
+#include <time.h>
 
 int  should_exit = 0;
 
+/* Wait for 0.1 sec.  */
+
+void
+small_delay ()
+{
+  const struct timespec ts = { 0, 1000000 }; /* 0.1 sec */
+  nanosleep (&ts, NULL);
+}
+
 int main ()
 {
   int  local_i = 0;
 
   while (! should_exit)
     {
+      /* Insert a small delay in order to avoid consuming all the CPU
+         while waiting for the debugger to take control.  */
+      small_delay ();
       local_i++;
     }
   return 0;
Index: attach.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/attach.exp,v
retrieving revision 1.12
diff -u -p -r1.12 attach.exp
--- attach.exp	7 Aug 2003 17:55:41 -0000	1.12
+++ attach.exp	20 Nov 2003 06:17:45 -0000
@@ -173,12 +173,16 @@ proc do_attach_tests {} {
 
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $"\
+      -re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*$gdb_prompt $"\
                       {pass "attach1, after setting file"}
       -re "$gdb_prompt $" {fail "attach1, after setting file"}
       timeout         {fail "(timeout) attach1, after setting file"}
    }
 
+   gdb_test "backtrace" \
+            ".*in nanosleep ().*in small_delay ().*in main ().*" \
+            "backtrace after attach1"
+
    # Verify that we can "see" the variable "should_exit" in the
    # program, and that it is zero.
    #
@@ -236,12 +240,16 @@ proc do_attach_tests {} {
    #
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
+      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
                       {pass "attach2"}
       -re "$gdb_prompt $" {fail "attach2"}
       timeout         {fail "(timeout) attach2"}
    }
 
+   gdb_test "backtrace" \
+            ".*in nanosleep ().*in small_delay ().*in main ().*" \
+            "backtrace after attach2"
+
    # Verify that we can modify the variable "should_exit" in the
    # program.
    #
@@ -253,16 +261,16 @@ proc do_attach_tests {} {
 
    # Verify that the modification really happened.
    #
-   send_gdb "tbreak 19\n"
+   send_gdb "tbreak 32\n"
    gdb_expect {
-      -re "Breakpoint .*at.*$srcfile, line 19.*$gdb_prompt $"\
+      -re "Breakpoint .*at.*$srcfile, line 32.*$gdb_prompt $"\
                       {pass "after attach2, set tbreak postloop"}
       -re "$gdb_prompt $" {fail "after attach2, set tbreak postloop"}
       timeout         {fail "(timeout) after attach2, set tbreak postloop"}
    }
    send_gdb "continue\n"
    gdb_expect {
-      -re "main.*at.*$srcfile:19.*$gdb_prompt $"\
+      -re "main.*at.*$srcfile:32.*$gdb_prompt $"\
                       {pass "after attach2, reach tbreak postloop"}
       -re "$gdb_prompt $" {fail "after attach2, reach tbreak postloop"}
       timeout         {fail "(timeout) after attach2, reach tbreak postloop"}
@@ -337,11 +345,15 @@ proc do_attach_tests {} {
 
    send_gdb "attach $testpid\n"
    gdb_expect {
-      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*main.*at .*$gdb_prompt $"\
+      -re "Attaching to process $testpid.*Reading symbols from $escapedbinfile.*$gdb_prompt $"\
                       {pass "attach when process' a.out not in cwd"}
       -re "$gdb_prompt $" {fail "attach when process' a.out not in cwd"}
       timeout         {fail "(timeout) attach when process' a.out not in cwd"}
    }
+
+   gdb_test "backtrace" \
+            ".*in nanosleep ().*in small_delay ().*in main ().*" \
+            "backtrace after attach when process' a.out not in cwd"
 
    send_gdb "kill\n"
    gdb_expect {

Re: [RFA/testsuite] attach.exp: Add small delay in busy loop...

[Michael Snyder]

Joel Brobecker wrote:
> Hello,
> 
> On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:
> 
>>>2003-11-18  J. Brobecker  <brobecker@gnat.com>
>>>
>>>       * gdb.base/attach.c: Add small delay in busy loop.
>>>       * gdb.base/attach.exp: Make some associated adjustments.
>>>
>>>OK to apply?
>>
>>Seems to work on Linux.  I'd sure like to see that backtrace test,
>>though, to confirm that we are able to build a meaningful machine
>>state after we attach.
> 
> 
> Here is a new version of the patch, with the backtraces in. I do have
> two FAILs though. The first FAIL comes from the following test:
> 
>    gdb_test "backtrace" \
>             ".*in nanosleep ().*in small_delay ().*in main ().*" \
>             "backtrace after attach2"
> 
> The logs show:
> 
>         backtrace
>         #0  0x400eb3b5 in ?? () from /lib/libc.so.6
>         #1  0x08048412 in small_delay () at ./gdb.base/attach.c:18
>         #2  0x08048435 in main () at ./gdb.base/attach.c:29
>         (gdb) FAIL: gdb.base/attach.exp: backtrace after attach2
> 
> So the problem is that GDB is unable to find the function name for
> frame $0. I think this comes from these warnings while performing
> the attach command:
> 
>         attach 3671
>         Attaching to process 3671
>         Reading symbols from /[...]/testsuite/gdb.base/attach...done.
>   -->   Symbols already loaded for /lib/libm.so.6
>   -->   Symbols already loaded for /lib/libc.so.6
>         Symbols already loaded for /lib/ld-linux.so.2
>         0x400eb3b5 in ?? () from /lib/libc.so.6^M 
>         (gdb) PASS: gdb.base/attach.exp: attach2
> 
> The second FAIL is identical.

Probably should explicitly clear the symbol tables between
one attach and the next.


> There is another thing that I think needs mentioning. I noticed I am
> the first one to introduce the use of nanosleep(). I think it's pretty
> portable, but I am having doubts. Does anybody know if it's not available
> on any platform. How about cygwin for instance?

Yeah, I remember having issues with it when I tried to write
thread tests.  I don't remember where it was missing -- maybe
Solaris?  I think your concern is valid -- nanosleep is not
guaranteed to be available everywhere.