gdb: handle relative paths to DWO files

DWARF allows .dwo file paths to be relative rather than absolute.

When they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file.  DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative.

In this case, GDB currently searches relative to its current working
directory, i.e. the directory from which the debugger was launched,
but not relative to the directory containing the built binary.  This
cannot be right, as the compiler, when generating the relative paths,
knows where it's building the binary but can have no idea where the
debugger will be launched.

The correct thing is to add the directory containing the binary to the
search paths used for resolving relative locations of dwo files. That
is what this patch does.

gdb/ChangeLog:

	* dwarf2/read.c (try_open_dwop_file): Add path for the binary to
	the search paths used resolve relative location of .dwo file.

gdb/testsuite/ChangeLog:

	* gdb.dwarf2/fission-relative-dwo.c: New file.
	* gdb.dwarf2/fission-relative-dwo.exp: New file.

1 files changed, 7 insertions, 0 deletions

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 43433f5..ed0d1c6 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -12723,6 +12723,13 @@ try_open_dwop_file (dwarf2_per_objfile *per_objfile,
   else
     search_path = debug_file_directory;
 
+  /* Add the path for the executable binary to the list of search paths.  */
+  std::string objfile_dir = ldirname (objfile_name (per_objfile->objfile));
+  search_path_holder.reset (concat (objfile_dir.c_str (),
+				    dirname_separator_string,
+				    search_path, nullptr));
+  search_path = search_path_holder.get ();
+
   openp_flags flags = OPF_RETURN_REALPATH;
   if (is_dwp)
     flags |= OPF_SEARCH_IN_PATH;