Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb-patches@sourceware.org
Subject: Re: Improve end check on rs6000 prologue analyzer
Date: Mon, 12 Mar 2007 21:02:00 -0000	[thread overview]
Message-ID: <200703122102.l2CL284g022996@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20070312121843.GA24487@caradoc.them.org> (message from Daniel 	Jacobowitz on Mon, 12 Mar 2007 08:18:43 -0400)

> Date: Mon, 12 Mar 2007 08:18:43 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sun, Mar 11, 2007 at 08:13:14PM +0100, Mark Kettenis wrote:
> > Here's a diff of gdb.sum without and with your diff (testsuite with
> > your diff).  The gdb.base/attach.exp failure is "normal"; the result
> > of that test flips between PASS and FAIL.  As you can see, there are
> > still "odd location failures".  Here is an excerpt from gdb.log for one:
> > 
> > (gdb) list
> > 134       char *ttyarg = NULL;
> > (gdb) step
> > 120     {
> > (gdb) PASS: gdb.gdb/selftest.exp: step over ttyarg initialization
> > list
> > 120     {
> > (gdb) FAIL: gdb.gdb/selftest.exp: step over ttyarg initialization ended up at odd location
> > step
> > 133       char *cdarg = NULL;
> > (gdb) PASS: gdb.gdb/selftest.exp: step over ttyarg initialization
> > 
> > This looks as pretty acceptable behaviour.  The initializations have
> > been moved into the prologue so while stepping over the
> > initializations, we hop back and forth.  I'm willing to accept this as
> > a testsuite problem ;-).
> 
> Me too.  But one thing is really puzzling!  We're testing the result
> of "list" here.  The huge gdb_expect includes these two:
> 
>             -re "\[0-9\]*\t\{\r\n$gdb_prompt $" {
>                 set description "step over initial brace"
>                 set command "step"
>             }
> 
>             -re "\[ \t\]+\{\r\n$gdb_prompt $" {
>                 setup_xfail "mips-*-irix5*"
>                 fail "$description ended up at odd location"
>             }
> 
> I would the first one to match.  It does plenty of times in my
> selftest.exp run.  The only way I can imagine for that second pattern
> to match would be for <space>{, but there shouldn't be a space there,
> just a tab - it comes from print_source_lines_base.  Any idea what
> happened?

Ah, I think I've seen this before.  On OpenBSD the tty subsystem does
tab expansion, wheras on Linux this doesn't happen by default.  So we
must match spaces as well as tabs here.  I think that means the second
pattern is really redundant.  How about the attached patch?


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* gdb.gdb/selftest.exp (do_steps_and_nexts): Match spaces as well
	as tabs.  Remove redundant test pattern.

Index: gdb.gdb/selftest.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.gdb/selftest.exp,v
retrieving revision 1.11
diff -u -p -r1.11 selftest.exp
--- gdb.gdb/selftest.exp 31 Jan 2007 19:32:12 -0000 1.11
+++ gdb.gdb/selftest.exp 12 Mar 2007 21:00:28 -0000
@@ -159,7 +159,7 @@ proc do_steps_and_nexts {} {
 		set description "next over textdomain PACKAGE"
 		set command "next"
 	    }
-	    -re "\[0-9\]*\t\{\r\n$gdb_prompt $" {
+	    -re "\[0-9\]+\[\t \]+\{\r\n$gdb_prompt $" {
 		set description "step over initial brace"
 		set command "step"
 	    }
@@ -197,10 +197,6 @@ proc do_steps_and_nexts {} {
 		set description "step over gdb_stderr initialization"
 		set command "step"
 	    }
-	    -re "\[ \t\]+\{\r\n$gdb_prompt $" {
-		setup_xfail "mips-*-irix5*"
-		fail "$description ended up at odd location"
-	    }
 	    -re ".*main.c.*No such file or directory.*$gdb_prompt $" {
 		setup_xfail "rs6000-*-aix3*"
 		fail "must be able to list source lines"


  reply	other threads:[~2007-03-12 21:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-29 21:37 Daniel Jacobowitz
2006-09-30 19:32 ` Mark Kettenis
2006-09-30 20:25   ` Daniel Jacobowitz
2006-10-17 21:21   ` Daniel Jacobowitz
2006-10-17 22:15     ` Mark Kettenis
2006-10-18  5:41     ` Wu Zhou
2006-10-18 14:18       ` Daniel Jacobowitz
2006-10-18 19:58     ` Mark Kettenis
2006-10-18 20:06       ` Daniel Jacobowitz
2006-11-30 20:12         ` Daniel Jacobowitz
2007-02-15 20:20           ` Aman Wardak
2007-03-09 15:05       ` Daniel Jacobowitz
2007-03-11 19:13         ` Mark Kettenis
2007-03-12 12:19           ` Daniel Jacobowitz
2007-03-12 21:02             ` Mark Kettenis [this message]
2007-03-12 21:09               ` Daniel Jacobowitz
2007-03-12 23:05                 ` Mark Kettenis
2007-03-13  4:24                   ` Eli Zaretskii
2007-04-10 21:10                     ` Daniel Jacobowitz
2007-04-11  3:35                       ` Eli Zaretskii
2007-04-11 11:11                         ` Daniel Jacobowitz
2007-03-13 17:37                   ` Daniel Jacobowitz
2007-04-17  2:02         ` Andreas Schwab
2007-04-17 15:02           ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703122102.l2CL284g022996@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox