Search .dwo in the binary directory.

.dwo files generated by the compiler usually resides in the same directory as
the generated binary itself. Add that binary to the list of directories to
search when searching for the .dwo file.

gdb/ChangeLog:

	* dwarf2/read.c (try_open_dwop_file): Include binary directory to
	the list of directories to search.  Search the path also when looking
	for a .dwo file.
---
 gdb/dwarf2/read.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Hi,

On 2/13/20 3:19 AM, Ali Tamur via gdb-patches wrote:
> .dwo files generated by the compiler usually resides in the same directory as
> the generated binary itself. Add that binary to the list of directories to
> search when searching for the .dwo file.

Thanks. This seems to be aligned with what find_separate_debug_file does:

   /* First try in the same directory as the original file.  */
   std::string debugfile = dir;
   debugfile += debuglink;

I guess you meant "Add that binary's path to the list ...".

> 
> gdb/ChangeLog:
> 
> 	* dwarf2/read.c (try_open_dwop_file): Include binary directory to
> 	the list of directories to search.  Search the path also when looking
> 	for a .dwo file.
> ---
>   gdb/dwarf2/read.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 7edbd9d7df..39f583e758 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -12012,9 +12012,14 @@ try_open_dwop_file (struct dwarf2_per_objfile *dwarf2_per_objfile,
>     else
>       search_path = debug_file_directory;
>   
> +  /* Add the directory of the binary to the search list.  */
> +  search_path_holder.reset(
> +     concat (ldirname (dwarf2_per_objfile->objfile->original_name).c_str (),
> +             dirname_separator_string, search_path, (char *) NULL));
> +  search_path = search_path_holder.get ();
> +
>     openp_flags flags = OPF_RETURN_REALPATH;
> -  if (is_dwp)
> -    flags |= OPF_SEARCH_IN_PATH;
> +  flags |= OPF_SEARCH_IN_PATH;

This was the only use of is_dwp. Now the parameter is unused in 
try_open_dwop_file and this and other functions should be updated. Do 
you know what is_dwp is originally for? Other than telling the function 
we're interested in reading a dwp file?

I see it was added back in 2012 by commit 
80626a55b99a0cb91546f334fc683f7a9f351101.

>   
>     gdb::unique_xmalloc_ptr<char> absolute_name;
>     desc = openp (search_path, flags, file_name,
>