public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [COMMIT PATCH] Make the maint.exp:'maint print objfiles' test less fragile.
@ 2013-11-20 17:58 Pedro Alves
  0 siblings, 0 replies; only message in thread
From: Pedro Alves @ 2013-11-20 17:58 UTC (permalink / raw)
  To: gdb-patches

I was "lucky" enough that an unrelated patch changed how many symtabs
GDB expands in a plain run to main, and that triggered a latent issue
in this test:

  PASS: gdb.base/maint.exp: maint print objfiles: header
  PASS: gdb.base/maint.exp: maint print objfiles: psymtabs
  FAIL: gdb.base/maint.exp: maint print objfiles: symtabs

The problem is in my case, expect is managing to alway put in the
buffer chunks like this:


  Psymtabs:
  ../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,

  Symtabs:
  ../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,


  Object file /usr/lib/debug/lib64/ld-2.15.so.debug:  Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms

  Psymtabs:
  bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
  0x1f65290, ...

Note: Psymtabs:/Symtabs:/Psymtabs:.

So, the loop matches the first Psymtabs in the buffer.  Then we're
left with


  ../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,

  Symtabs:
  ../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,


  Object file /usr/lib/debug/lib64/ld-2.15.so.debug:  Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms

  Psymtabs:
  bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
  0x1f65290, ...

In the next iteration, because the psymtabs regex comes first, we
match with the Psymtabs: line, then of course, end up with just

  bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
  0x1f65290, ...

in the buffer.  The "Symtabs:" line is lost.  expect then reads more
gdb output, and manages to again retrieve the same pattern.  Rinse,
repeat, and the test never matches any "Symtab:" line.

We don't know the order the matches lines will appear, so the fix is
to consume one line at a time, and run it through all three milestone
regexes.

gdb/testsuite/
2013-11-20  Pedro Alves  <palves@redhat.com>

	* gdb.base/maint.exp (maint print objfiles): Consume one line at a
	time, and run it through all three milestone regexes.
---
 gdb/testsuite/gdb.base/maint.exp | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp
index 9425f2b..d3409b6 100644
--- a/gdb/testsuite/gdb.base/maint.exp
+++ b/gdb/testsuite/gdb.base/maint.exp
@@ -181,9 +181,18 @@ set keep_looking 1
 while {$keep_looking} {
     gdb_expect  {
 
-	-re ".*Object file.*maint($EXEEXT)?:  Objfile at $hex, bfd at $hex, \[0-9\]* minsyms\[\r\t \]+\n" { set header 1 }
-	-re ".*Psymtabs:\[\r\t \]+\n" { set psymtabs 1 }
-	-re ".*Symtabs:\[\r\t \]+\n" { set symtabs 1 }
+	-re "\r\n" {
+	    set output $expect_out(buffer)
+	    if {[regexp ".*Object file.*maint($EXEEXT)?:  Objfile at ${hex}" $output]} {
+		set header 1
+	    }
+	    if {[regexp ".*Psymtabs:\[\r\t \]+\n" $output]} {
+		set psymtabs 1
+	    }
+	    if {[regexp ".*Symtabs:\[\r\t \]+\n" $output]} {
+		set symtabs 1
+	    }
+	}
 
 	-re ".*$gdb_prompt $" { 
 	    set keep_looking 0
-- 
1.7.11.7

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-11-20 17:28 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-20 17:58 [COMMIT PATCH] Make the maint.exp:'maint print objfiles' test less fragile 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).