gdb.base/dso2dso.exp sometimes broken

gdb.base/dso2dso.exp sometimes broken

Keith reported that gdb.base/dso2dso.exp is broken, with the following
error:

| $ make check RUNTESTFLAGS=dso2dso.exp
| [snip]
| Running ../../../src/gdb/testsuite/gdb.base/dso2dso.exp ...
| ERROR: tcl error sourcing ../../../src/gdb/testsuite/gdb.base/dso2dso.exp.
| ERROR: couldn't open
| "../../../src/gdb/testsuite/gdb.base/../../../src/gdb/testsuite/gdb.base/dso2dso-dso1.c":
| no such file or directory
|     while executing
| "error "$message""
|     (procedure "gdb_get_line_number" line 14)
|     invoked from within
| "gdb_get_line_number "STOP HERE" $srcfile_libdso1"
|     (file "../../../src/gdb/testsuite/gdb.base/dso2dso.exp" line 60)
|     invoked from within
| "source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     ("uplevel" body line 1)
|     invoked from within
| "uplevel #0 source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
|     invoked from within
| "catch "uplevel #0 source $test_file_name""

This happens because gdb_get_line_number will prepend $srcdir/$subdir
if the given filename does not start with "/", and this happens when
GDB was configured using a relative path to the configure script.
When using an absolute path like I do, we avoid the pre-pending that
Keith is seeing.

gdb/testsuite/ChangeLog:

        Keith Seitz  <keiths@redhat.com>:
        * gdb.base/dso2dso.exp: Pass basename of source file in call
        to gdb_get_line_number.

Tested on x86_64-linux with both scenarios.