[PATCH] Search .dwo in the binary directory.

[PATCH] Search .dwo in the binary directory.

[Ali Tamur via gdb-patches]

.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(-)

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;
 
   gdb::unique_xmalloc_ptr<char> absolute_name;
   desc = openp (search_path, flags, file_name,
-- 
2.25.0.265.gbab2e86ba0-goog

Re: [PATCH] Search .dwo in the binary directory.

[Luis Machado]

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,
> 

Re: [PATCH] Search .dwo in the binary directory.

[Tom Tromey]

>>>>> "Ali" == Ali Tamur via gdb-patches <gdb-patches@sourceware.org> writes:

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

Thanks for the patch.
I didn't see a review of this, apologies if it's a duplicate.

Ali> +  /* Add the directory of the binary to the search list.  */
Ali> +  search_path_holder.reset(
Ali> +     concat (ldirname (dwarf2_per_objfile->objfile->original_name).c_str (),
Ali> +             dirname_separator_string, search_path, (char *) NULL));

If search_path_holder was already set, then I think this will leak the
old value.

Maybe changing search_path_holder to std::string would be better, since
it would make it simpler to avoid leaks.

Ali> +  search_path = search_path_holder.get ();
Ali> +
Ali>    openp_flags flags = OPF_RETURN_REALPATH;
Ali> -  if (is_dwp)
Ali> -    flags |= OPF_SEARCH_IN_PATH;
Ali> +  flags |= OPF_SEARCH_IN_PATH;
 
This line can be merged into the declaration of flags.

How did you test this patch?

Tom