find_and_open_source in symtab_to_fullname

[Yao Qi <qiyaoltc@gmail.com>]

Hi,
I see the following unexpected behaviour of inserting breakpoints in gdb.base/dprint.exp,

 (gdb) dprintf 28,"arg=%d, g=%d\n", arg, g
 Dprintf 3 at 0x400afc: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28. (2 locations)

Two locations are created instead of one.

3       dprintf        keep y   <MULTIPLE>
        printf "arg=%d, g=%d\n", arg, g^M
3.1                         y     0x0000000000400afc in foo at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28^M
3.2                         y     0x0000007fb7e34598 in __dprintf at dprintf.c:28

Breakpoint location 3.2 looks wired, and GDB can't generate target
command for this location, so the following test fails.

Two breakpoint locations are created even for normal breakpoint, see,

 (gdb) break 28
 Breakpoint 4 at 0x400afc:
 /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28. (2 locations)

4       breakpoint     keep y   <MULTIPLE>         ^M
4.1                         y     0x0000000000400afc in foo at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28^M
4.2                         y     0x0000007fb7e34598 in __dprintf at dprintf.c:28

the dprintf.c (which has __dprintf) is from glibc, and my glibc build
has debug information.

 <0><a7596>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <a7597>   DW_AT_producer    : (indirect string, offset: 0x6b): GNU C 4.9.2 20140904 (prerelease) -march=armv8-a -mlittle-endian -mabi=lp64 -g -O2 -std=gnu99 -fgnu89-inline -fmerge-all-constants -frounding-math -fPIC
    <a759b>   DW_AT_language    : 1     (ANSI C)
    <a759c>   DW_AT_name        : (indirect string, offset: 0xe27c): dprintf.c
    <a75a0>   DW_AT_comp_dir    : (indirect string, offset: 0xbbef): /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common

Then I start to investigate how is the 2nd breakpoint location
generated.  When we type "break 28", GDB parses the linespec, and find
the right address to insert breakpoint.  According to linespec,
https://sourceware.org/gdb/current/onlinedocs/gdb/Linespec-Locations.html
"break 28" means insert the breakpoint on line 28 of current source
file, which is XXX/gdb.base/dprintf.c.  However, GDB will also collect
all symtabs which matches XXX/gdb.base/dprintf.c (by
collect_symtabs_from_filename), and during the iterations, dprintf.c
from glibc is collected by mistake.

GDB finds the full file name by symtab's filename field and
SYMTAB_DIRNAME macro.  In my case, symtab's filename is dprintf.c and
SYMTAB_DIRNAME is /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common
but find_and_open_source still finds dprintf.c in a list of directories,
/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base:/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common:$cwd
so /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c
exists and GDB thinks dprintf.c from glibc is found.

I understand the problem but not sure what is the right fix.  Any ideas?
One idea is to not call collect_symtabs_from_filename if we know
FULLNAME is an absolute path, like this below.  Is it a minor
performance optimization?

-- 
Yao (齐尧)

diff --git a/gdb/linespec.c b/gdb/linespec.c
index b2233b9..ab77e7e 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -1842,7 +1842,14 @@ create_sals_line_offset (struct linespec_state *self,
       fullname = symtab_to_fullname (self->default_symtab);
       VEC_pop (symtab_ptr, ls->file_symtabs);
       VEC_free (symtab_ptr, ls->file_symtabs);
-      ls->file_symtabs = collect_symtabs_from_filename (fullname);
+
+      if (IS_ABSOLUTE_PATH (fullname))
+       {
+         VEC_safe_push (symtab_ptr, ls->file_symtabs, self->default_symtab);
+       }
+      else
+       ls->file_symtabs = collect_symtabs_from_filename (fullname);
+
       use_default = 1;
     }