gdb.mi/*.exp and absolute line numbers

gdb.mi/*.exp and absolute line numbers

[Michael Chastain]

Ouch!  I'm pulling on this loose thread, and a whole yard of the test
suite unravelled!  I need some help.

Here is the situation:

(1) gcc HEAD has a new warning:
      incompatible implicit declaration of built-in function.
(2) gcc warnings make the callers of gdb_compile bomb out.
(3) the way to fix the warning is to add the right #include <...> lines.
(4) i fixed all the instances in gdb.base/*.c.
(5) the problem is also in:
      gdb.mi/basics.c gdb.mi/gdb701.c gdb.mi/var-cmd.c
(6) none of those files have a copyright notice

So I try adding a copyright notice to gdb.mi/basics.c.  Boom, twenty
gdb.mi/*.exp scripts regress because they depend on absolute line
numbers:

  mi-break.exp mi-cli.exp mi-diassemble.exp mi-eval.exp mi-file.exp
  mi-return.exp mi-simplerun.exp mi-stack.exp mi-stepi.exp mi-watch.exp
  mi2-break.exp mi2-cli.exp mi2-disassemble.exp mi2-eval.exp
  mi2-file.exp mi2-return.exp mi2-simplerun.exp mi2-stack.exp
  mi2-stepi.exp mi2-watch.exp

I'm disconcerted.

The natural fix is to use gdb_get_line_number in gdb.mi/*.exp.  However,
gdb_get_line_number uses the CLI commands "list" and "search".  I can't
find any MI equivalents.

But I don't see why gdb_get_line_number has to talk to gdb at all.  I
think it could just be implemented in native tcl: open the file, read
each line, match the search string.  Then gdb_get_line_number would work
with all user interfaces.

Can you remember the reason that gdb_get_line_number talks to gdb
rather than doing its own scanning?  Perhaps the reason was just
"it's easier to talk to gdb than to write a bunch of tcl".

So my proposal is:

  rewrite gdb_get_line_number in tcl
    (either clone the function or rewrite existing implementation)
  add gdb_get_line_number to gdb.mi/*.exp
  add copyright notices to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
  add #include lines to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
  ... so the the gdb test suite will work with gcc HEAD

Another way out.  Less work, but cheesier: put the copyright notices for
basics.c, gdb701.c, and var-cmd.c in a separate COPYRIGHT file, with a
note that these files have absolute line numbers and cannot easily be
edited.

Ideas?

Michael C

Re: gdb.mi/*.exp and absolute line numbers

[Daniel Jacobowitz]

On Thu, Aug 05, 2004 at 05:21:08AM -0400, Michael Chastain wrote:
>   rewrite gdb_get_line_number in tcl
>     (either clone the function or rewrite existing implementation)

Please do!  If you need help with the TCL, I can help also.  The result
will probably be faster, and definitely clutter the logs less.

-- 
Daniel Jacobowitz

Re: gdb.mi/*.exp and absolute line numbers

[Michael Chastain]

Daniel Jacobowitz <drow@false.org> wrote:
> Please do!  If you need help with the TCL, I can help also.  The result
> will probably be faster, and definitely clutter the logs less.

Here's some work in progress.  Can you eyeball it for me?

It works on a few different configurations in my test bed.

The old code had side effects on gdb, like setting gdb's idea of the
current file and line number.  Fortunately none of the 94 callers takes
advantage of these side effects.

I'm interested in:

. source code format -- i'm making it up as i go along.
  if it looks weird, grab a chunk of code and reformat it with
  your favorite style.

. i wrapped all the filesystem calls with "catch { ... } message".
  did i do this right?

. defaults for the file name and file directories -- i had to be
  compatible with the old code, but it is baroque.  any ideas?

Michael C

# gdb_get_line_number TEXT [FILE]
#
# Search the source file FILE, and return the line number of the
# first line containing TEXT.  If no match is found, return -1.
# 
# TEXT is a string literal, not a regular expression.
#
# The default value of FILE is "$srcdir/$subdir/$srcfile".  If FILE is
# specified, and does not start with "/", then it is assumed to be in
# "$srcdir/$subdir".  This is awkward, and can be fixed in the future,
# by changing the callers and the interface at the same time.
# In particular: gdb.base/break.exp, gdb.base/condbreak.exp,
# gdb.base/ena-dis-br.exp.
#
# Use this function to keep your test scripts independent of the
# exact line numbering of the source file.  Don't write:
# 
#   send_gdb "break 20"
# 
# This means that if anyone ever edits your test's source file, 
# your test could break.  Instead, put a comment like this on the
# source file line you want to break at:
# 
#   /* breakpoint spot: frotz.exp: test name */
# 
# and then write, in your test script (which we assume is named
# frotz.exp):
# 
#   send_gdb "break [gdb_get_line_number "frotz.exp: test name"]\n"
#
# (Yes, Tcl knows how to handle the nested quotes and brackets.
# Try this:
# 	$ tclsh
# 	% puts "foo [lindex "bar baz" 1]"
# 	foo baz
# 	% 
# Tcl is quite clever, for a little stringy language.)
#
# ===
#
# The previous implementation of this procedure used the gdb search command.
# This version is different:
#
#   . It works with MI, and it also works when gdb is not running.
#
#   . It operates on the build machine, not the host machine.
#
#   . For now, this implementation fakes a current directory of
#     $srcdir/$subdir to be compatible with the old implementation.
#     This will go away eventually and some callers will need to
#     be changed.
#
#   . The TEXT argument is literal text and matches literally,
#     not a regular expression as it was before.
#
#   . State changes in gdb, such as changing the current file
#     and setting $_, no longer happen.
#
# After a bit of time we can forget about the differences from the
# old implementation.
#
# --chastain 2004-08-05

proc gdb_get_line_number { text { file "" } } {
    global srcdir
    global subdir
    global srcfile

    if { "$file" == "" } then {
	set file "$srcfile"
    }
    if { ! [regexp "^/" "$file"] } then {
	set file "$srcdir/$subdir/$file"
    }

    if { [ catch { set fd [open "$file"] } message ] } then {
	perror "$message"
	return -1
    }

    set found -1
    for { set line 1 } { 1 } { incr line } {
	if { [ catch { set nchar [gets "$fd" body] } message ] } then {
	    perror "$message"
	    return -1
	}
	if { $nchar < 0 } then {
	    break
	}
	if { [string first "$text" "$body"] >= 0 } then {
	    set found $line
	    break
	}
    }

    if { [ catch { close "$fd" } message ] } then {
	perror "$message"
	return -1
    }

    return $found
}

Re: gdb.mi/*.exp and absolute line numbers

[Jim Blandy]

Michael Chastain <mec.gnu@mindspring.com> writes:
> Can you remember the reason that gdb_get_line_number talks to gdb
> rather than doing its own scanning?  Perhaps the reason was just
> "it's easier to talk to gdb than to write a bunch of tcl".

That was the reason.

Re: gdb.mi/*.exp and absolute line numbers

[Michael Chastain]

Well all right, one re-implementation of gdb_get_line_number in
native tcl coming right up.

This is high priority to me because that new gcc warning wipes out most
of the gdb.mi results.

I used to hate and not really get Tcl.  Then I learned Perl.  I totally
heart Perl.  Now I think of Tcl as Perl's demented step-sibling, and I
can wield it a lot better.

Michael C

Re: gdb.mi/*.exp and absolute line numbers

[Eli Zaretskii]

> Date: Thu, 05 Aug 2004 05:21:08 -0400
> From: Michael Chastain <mec.gnu@mindspring.com>
> 
> So my proposal is:
> 
>   rewrite gdb_get_line_number in tcl
>     (either clone the function or rewrite existing implementation)
>   add gdb_get_line_number to gdb.mi/*.exp
>   add copyright notices to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
>   add #include lines to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
>   ... so the the gdb test suite will work with gcc HEAD
> 
> Another way out.  Less work, but cheesier: put the copyright notices for
> basics.c, gdb701.c, and var-cmd.c in a separate COPYRIGHT file, with a
> note that these files have absolute line numbers and cannot easily be
> edited.
> 
> Ideas?

Do we have to put the copyright text at the beginning of a file?  If
not, you could add it to the end, which will keep the line info
intact.

But I see you already decided on the first approach.

Re: gdb.mi/*.exp and absolute line numbers

[Michael Chastain]

"Eli Zaretskii" <eliz@gnu.org> wrote:
eliz> Do we have to put the copyright text at the beginning of a file?  If
eliz> not, you could add it to the end, which will keep the line info
eliz> intact.

We could do that.

The gnu maintainer's guide says:

  http://www.gnu.org/prep/maintain_8.html

  4.4 Copyright Notices
  
  ... Some formats do not have room for textual annotations;
  for these files, state the copyright and copying permissions in
  a README file in the same directory.

  Change log files should have a copyright notice and license notice
  at the end, since new material is added at the beginning but the end
  remains the end.

(Ouch, I need to write a copyright notice for testsuite/ChangeLog.)

My understanding of U.S. copyright law is that the copyright notice has
to be in a prominent place, so that when a reasonable person starts
reading the work, they will have reasonable notice of the copyright.
That way, when a copyright holder takes a copyright infringer to court,
and the copyright infringer says "I didn't see the copyright notice" and
tries to make a case for innocent infringement, the copyright holder can
say "It was right there in your face where any normal person would see
it!", and make a case for willful infringement.

Willful infringement means more damages, which means more negotiating
power for the copyright holder in out-of-court negotiations.

eliz> But I see you already decided on the first approach.

Yeah.  The copyright question is incidental.  It came up because I want
to make other changes to these files, and I don't like to modify a file
that needs a copyright notice and doesn't have one.

(Double ouch on testsuite/ChangeLog).

The real issue is that some of these testsuite/*.c files cannot be
edited for any reason, or they break.  Imagine if the gdb doco was
kept in gdb.info format, not gdb.texinfo, and every time you added
something, you had to hand-adjust the Tag Table at the end or it
would break.  Hence my push to make gdb_get_line_number usable in
gdb.mi, and then use it in gdb.mi.

Michael C

Re: gdb.mi/*.exp and absolute line numbers

[Andrew Cagney]

Other than MI I'm not sure what interest I've got in this.  Consider the 
MI fall-out fairly obvious :-)

(What happens with a soft-link or file copy (where the file name isn't 
in $srcdir) as is done with the asm tests).

Andrew

Re: gdb.mi/*.exp and absolute line numbers

[Michael Chastain]

Andrew Cagney <cagney@gnu.org> wrote:
> (What happens with a soft-link or file copy (where the file name isn't 
> in $srcdir) as is done with the asm tests).

This call would stop working:

  [gdb_get_line_number "foo" arch.inc]

However this call would work fine:

  [gdb_get_line_number "foo" ${asm-arch}.inc]

Fortunately there are no such calls in the corpus, so it won't hurt when
I change the semantics from "gdb looks for the file on the host machine"
to "tcl looks for the file on the build machine".

The test script always has to know the names of the files on the build
machine, in order to get them to the host machine in the first place.

Something like gdb.stabs/weird.exp would be more painful, because it
actually runs 'sed' on the *host* machine to preprocess files before
feeding them to gdb_compile.  For something like that, if it called
gdb_get_line_number, I would have to rip out the call and replace
it with an explicit call to "gdb_test search".

Michael C