[rfc/testsuite] editor.exp: new test script for "edit" command

[rfc/testsuite] editor.exp: new test script for "edit" command

[Michael Elizabeth Chastain]

Here is a new test file.

"edit" is a little command that locates the current line number and
source file and opens an editor for it.

The code for edit_command has its own filename construction code and
this code does not work with dwarf-2.  See PR gdb/1608, and I've heard
from another user who ran into the same problem.

This script sets the environment variable $EDITOR to "echo",
so that the arguments just appear in standard output and the test
script doesn't have an editor popping up.  gdb.log looks like this:

  # gdb.log
  (gdb) PASS: gdb.base/editor.exp: continue to marker_one
  edit
  +24 .///berman/fsf/_current_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/editor.c
  (gdb) PASS: gdb.base/editor.exp: capture editor command arguments

And then the script checks the line number (24) and the filename
(".///berman/fsf/.../editor.c").  It checks the filename by calling
TCL "file exists ...".

  # gdb.log
  PASS: gdb.base/editor.exp: line number argument
  KFAIL: gdb.base/editor.exp: filename argument (PRMS: gdb/1608)

There is lots more that this script could do, such as creating
multiple source files, source files with code in '*.h' files,
and -- especially -- source files with relative paths, because
the treatment of absolute and relative paths is different.

But this is a start.

I'm particularly interested in whether this bit of TCL is okay:

  if { [file exists $actual_file] } then {
    ...
  } else {
    ...
  }

Should I use "file exists ..." or "remote_file build exists ..." here?

This is just RFC so far.  I need to understand the remote issue,
and I suspect that I'm going to need a lot of "remote_file ..."
stuff to create various files on the build system and manipulate
them there.

Michael C

2004-07-23  Michael Chastain  <mec.gnu@mindspring.com>

	Test for PR cli/1608.
	* gdb.base/editor.exp: New file.
	* gdb.base/editor.c: New file.

=== editor.c

/* This test program is part of GDB, the GNU debugger.

   Copyright 2004 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
   */

int value = 117;

int marker_1 ()
{
    return value;  /* marker one */
}

int main ()
{
    marker_1 ();
    return 0;
}

=== editor.exp

# This test script is part of GDB, the GNU debugger.
# Copyright 2004 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  

# Test the "edit" command.

if $tracelevel {
    strace $tracelevel
}

set testfile "editor"
set srcfile ${testfile}.c
set binfile ${objdir}/${subdir}/${testfile}

if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable "debug"] != "" } {
    perror "Couldn't compile ${srcfile}"
    return -1
}

# Run gdb with EDITOR set to "echo".  There is no "set editor"
# command so I have to set this in the environment.

global env
set old_EDITOR ""
if [info exists env(EDITOR)] {
    set old_EDITOR $env(EDITOR)
    set env(EDITOR) "echo"
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

if ![runto_main] then {
    perror "couldn't run to breakpoint"
    continue
}

set marker_one [gdb_get_line_number "marker one"]
gdb_test "break $marker_one" \
    "Breakpoint.*at.* file .*$srcfile, line $marker_one." \
    "breakpoint marker_one"
gdb_test "continue" \
    "Continuing.*marker one.*" \
    "continue to marker_one"

# Capture the editor command line.
# It looks like this:
#   +24 /path/path/path/$srcfile

set actual_line "no line"
set actual_file "no file"
set testname "capture editor command arguments"
gdb_test_multiple "edit" $testname {
    -re "\[+\](\[0-9\]+) (.*)\r\n$gdb_prompt $" {
	set actual_line $expect_out(1,string)
	set actual_file $expect_out(2,string)
	pass $testname
    }
}

# Check the line number argument.

if { $actual_line == $marker_one } then {
    pass "line number argument"
} else {
    fail "line number argument"
}

# Check the filename.  It might have been canonicalized in some way.
# Just check that I can read the source file.

if { [file exists $actual_file] } then {
    pass "filename argument"
} else {
    kfail "gdb/1608" "filename argument"
}

# Restore EDITOR.

if [info exists env(EDITOR)] {
    set env(EDITOR) $old_EDITOR
}

# More stuff to add:
#   "edit" with no source file.
#   A source file in the current directory on the build machine.
#   A source file with a relative path on the build machine.
#   Multiple source files.
#   Breakpoints in header files.
#   Source files with #line comments.

Re: [rfc/testsuite] editor.exp: new test script for "edit" command

[Daniel Jacobowitz]

On Fri, Jul 23, 2004 at 02:47:26AM -0400, Michael Chastain wrote:
> I'm particularly interested in whether this bit of TCL is okay:
> 
>   if { [file exists $actual_file] } then {
>     ...
>   } else {
>     ...
>   }
> 
> Should I use "file exists ..." or "remote_file build exists ..." here?
> 
> This is just RFC so far.  I need to understand the remote issue,
> and I suspect that I'm going to need a lot of "remote_file ..."
> stuff to create various files on the build system and manipulate
> them there.

Two things:
  - DejaGNU assumes that "build" is where tests are being run.
    There's never a need to use remote_file build.  Sometimes
    it is good for consistency, but see the next point.
  - GDB's testsuite assumes that host and build are the same.
    So I don't know if the consistency is worth it unless someone
    cares about separating them.


-- 
Daniel Jacobowitz

Re: [rfc/testsuite] editor.exp: new test script for "edit" command

[Michael Chastain]

Daniel Jacobowitz writes:
>   - GDB's testsuite assumes that host and build are the same.
>     So I don't know if the consistency is worth it unless someone
>     cares about separating them.

I looked into this.  Let me sort my thoughts.

build  == machine where dejagnu is running.
host   == machine where gdb and gcc is running.
target == machine where test program (test.exe) is running

Dejagnu supports separate build and host machines

In default_target_compile, if host is remote from build, then
default_target_compile calls remote_download to copy the test program
source code (test.c) from build to host.  default_target_compile also
calls remote_upload to copy a.out back from host to build.

If the test.c includes test.h, then test.exp has to download this file
onto the host by hand.

gdb.base/list.exp actually does this:

  remote_download host ${srcdir}/${subdir}/list0.h list0.h
  ...
  remote_exec build "rm -f list0.h"

However, all these test scripts neglect to download their *.h files:

  gdb.arch/i386-sse.exp
  gdb.base/lineinc.exp
  gdb.base/macscp.exp
  gdb.base/overlays.exp
  gdb.base/shlib-call.exp
  gdb.cp/m-static.exp
  gdb.cp/rtti.exp
  gdb.hp/gdb.compat/xdb2.exp
  gdb.hp/gdb.objdbg/objdbg01.exp
  gdb.hp/gdb.objdbg/objdbg04.exp
  gdb.stabs/exclfwd.exp

There are other issues with separate build and host, like core files.
gdb creates them on the host machine, but then gcore.exp expects to see
them on the build machine.

I don't think there's much of a demand for the gdb testsuite to support
separate build and host machines.  So I'm going to propose a policy
change, in the form of a documentation patch to the 'Testsuite' section
of gdbint.texinfo, that the gdb test suite does not support separate
build and host machines.  (Of course we support separate host/build and
target machines!)

Michael C