Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: fnasser@redhat.com, jimb@redhat.com
Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [Jim Blandy <jimb@redhat.com>] RFA: Check that `Local' is not in scope when it shouldn't be
Date: Mon, 23 Dec 2002 22:51:00 -0000	[thread overview]
Message-ID: <200212240637.gBO6bOS20981@duracef.shout.net> (raw)

Regarding this patch:

  2002-11-14  Jim Blandy  <jimb@redhat.com>

	* local.exp: Don't expect Local to be in scope in main; it's local
	to foobar.  Check for it there, and check that it's not present in
	main.
	* local.cc (marker2): New function.
	(foobar): Call marker1.
	(main): Call marker2 instead of marker1.

The first part of this patch, "Don't expect Local to be in scope in main;
it's local to foobar.", is approved.  I agree with your analysis and most
of your solution.  I don't like the second call to "runto 'marker2'",
because "runto" restarts gdb needlessly.  I think it's better to do:

  gdb_test "break marker2" ...
  gdb_test "continue" "Break.* marker2 ... at ..."

But the test works correctly as you wrote it, and the existing code 
doesn't, so I approve it and someone can rewrite the second "runto"
after you commit this.

The second part, "... check that it's not present in main",
is not approved.  You wrote the KFAIL like this:

  # setup_kfail "gdb/825"
  gdb_test "ptype Local" "No symbol \"Local\" in current context.*" \
    "Local out of scope (gdb/825)"

There is a coding style issue here.  My vision is that KFAIL's are always
a response to specific known bad output from gdb, like this:

  send_gdb "ptype Local\n"
  gdb_expect {
    -re "No symbol \"Local in current context.\r\n$gdb_prompt $" {
      pass "ptype Local"
    }
    -re "... big regular expression that matches the correct declaration of Local from the wrong scope ..." {
      # comment here about which configurations we expect this for
      kfail "gdb/825" "ptype Local"
    }
    -re ".*$gdb_prompt $" {
      fail "ptype Local"
    }
    timeout {
      fail "ptype Local (timeout)"
    }
  }

This way, the test can still generate FAIL if gdb starts acting in a
new unknown way.  The first test actually does this; it went from FAIL
(gdb/483) to an unmarked FAIL, which indicated that there was a problem
(which turned out to be in the test script itself).

I think this issue needs some discussion and then a decision from
FernandoN or AndrewC so I'd like to hold off on the second test in
this patch while we resolve this.

(I spent too much time on this patch because I started doing my own
update of Local.exp with my style of KFAIL's everywhere.  Then I decided
it's better just to respond to JimB and work on an all-updated local.exp
later.)

Michael C


             reply	other threads:[~2002-12-24  6:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-23 22:51 Michael Elizabeth Chastain [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-05  6:23 Michael Elizabeth Chastain
2002-12-20 21:12 Michael Elizabeth Chastain
2002-12-20 10:56 Jim Blandy
2002-12-20 11:19 ` Daniel Jacobowitz
2002-12-20 12:05   ` David Carlton
2002-12-20 12:01 ` David Carlton
2002-12-20 12:18   ` David Carlton
2003-02-04 22:02 ` Jim Blandy
2003-02-04 22:16   ` David Carlton
2003-02-05  5:49     ` Jim Blandy

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=200212240637.gBO6bOS20981@duracef.shout.net \
    --to=mec@shout.net \
    --cc=ac131313@redhat.com \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    /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