[PATCH][RFC] symfile.c:find_separate_debug_file: additional path

[PATCH][RFC] symfile.c:find_separate_debug_file: additional path

[Tiago]

Recently I added a directory with debug symbols to the 
"debug-file-directory" variable in .gdbinit, expecting that gdb would 
search for the debug file mentioned in the ".gnu_debuglink" section in 
this directory. That is not the case.

If the binary is "/very/big/path/binary", gdb searchs for symbols in 
"/dir/with/symbols/very/big/path/[.gnu_debuglink]", which is fine, as 
this is a traditional path. But gdb never checks 
"/dir/with/symbols/[.gnu_debuglink]". I found this behaviour 
counter-intuitive. And furthermore I really needed to get gdb to find 
the symbols automatically without changing the location of any file, and 
without creating symlinks.

So in order to get gdb to find the debug symbols on the root of the 
debugfile directory (i.e. "/dir/with/symbols/[.gnu_debuglink]"), I 
created the patch presented bellow, it simply adds the root of the 
debugfile directories as an extra search path. And it works fine.

Is there an easier way to obtain the desirable behaviour? (note that I 
cannot change the location of binaries or debug symbols. I can only 
change .gdbinit, the .gnu_debuglink section of the binaries and gdb)

Is this patch suitable for the main repo?


Best Regards,
Tiago Queiroz

2013-11-01  Tiago Queiroz <tiagofaq@gmail.com>
     * symfile.c:find_separate_debug_file: Add an extra search path.
---
  gdb/symfile.c |    9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/gdb/symfile.c b/gdb/symfile.c
index 5ed2591..49940c9 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1546,6 +1546,15 @@ find_separate_debug_file (const char *dir,
           if (separate_debug_file_exists (debugfile, crc32, objfile))
             return debugfile;
         }
+
+      /* Try the root of the global debugfile directory.  */
+      strcpy (debugfile, debugdir);
+      strcat (debugfile, "/");
+      strcat (debugfile, debuglink);
+
+      if (separate_debug_file_exists (debugfile, crc32, objfile))
+        return debugfile;
+
      }

    do_cleanups (back_to);
-- 
1.7.9.5

Re: [PATCH][RFC] symfile.c:find_separate_debug_file: additional path

[Tom Tromey]

>>>>> "Tiago" == Tiago  <tiagofaq@gmail.com> writes:

Tiago> Recently I added a directory with debug symbols to the
Tiago> "debug-file-directory" variable in .gdbinit, expecting that gdb would
Tiago> search for the debug file mentioned in the ".gnu_debuglink" section in
Tiago> this directory. That is not the case.

Yeah.  This way is contrary to the gdb documentation of the feature.

Tiago> Is there an easier way to obtain the desirable behaviour? (note that I
Tiago> cannot change the location of binaries or debug symbols. I can only
Tiago> change .gdbinit, the .gnu_debuglink section of the binaries and gdb)

Tiago> Is this patch suitable for the main repo?

What system is this that can't be changed?  I think it would be
preferable to make your system work the way it is all documented to
work.

Though, really, you should be using build-ids and not this stuff anyway.

In any case this patch needs a documentation fix before it could be
considered.  I suppose I'm mildly against it, on the theory that the
existing mechanisms are documented and sufficient.

Tom

Re: [PATCH][RFC] symfile.c:find_separate_debug_file: additional path

[Tiago Queiroz]

Hi Tom,

I played with the build-ids for a bit, and I should be able to solve
my problem using them. (It is true that I will have to move some files
around, but with build-ids the location of the debug file is
independent of the location of the executable, which makes things a
bit easier).

Anyway, thanks for mentioning the build-ids.

As for the extra search path I came with the following pros and cons:
Pros
- It would make it easier to set up an environment where gdb
automatically finds and loads debug information.
- All current instances of automatic loading would still work (for
this to happen the new path must be the last place where gdb looks for
debug files, this would require a small modification to my patch).
- In some edge cases it might be the only cost-effective way to make
automatic loading possible.

Cons
- It would promote the bad practice of always leaving the debug files
in the root of some debug file directory, which would lead to
collisions (i.e. two apps try to store their "server.debug" file on
the same directory) and shadowing (i.e. the file
/usr/local/app1/debug/server.debug shadows the file
/usr/local/app2/debug/server.debug).

I am a bit on the fence about this. (Especially after learning about build-ids.)
At any rate, if someone expresses some interest on this feature I
would be glad to submit an improved patch for consideration (with the
appropriate modifications to the documentation).


Best Regards,
Tiago Queiroz

On Fri, Nov 1, 2013 at 8:52 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Tiago" == Tiago  <tiagofaq@gmail.com> writes:
>
> Tiago> Recently I added a directory with debug symbols to the
> Tiago> "debug-file-directory" variable in .gdbinit, expecting that gdb would
> Tiago> search for the debug file mentioned in the ".gnu_debuglink" section in
> Tiago> this directory. That is not the case.
>
> Yeah.  This way is contrary to the gdb documentation of the feature.
>
> Tiago> Is there an easier way to obtain the desirable behaviour? (note that I
> Tiago> cannot change the location of binaries or debug symbols. I can only
> Tiago> change .gdbinit, the .gnu_debuglink section of the binaries and gdb)
>
> Tiago> Is this patch suitable for the main repo?
>
> What system is this that can't be changed?  I think it would be
> preferable to make your system work the way it is all documented to
> work.
>
> Though, really, you should be using build-ids and not this stuff anyway.
>
> In any case this patch needs a documentation fix before it could be
> considered.  I suppose I'm mildly against it, on the theory that the
> existing mechanisms are documented and sufficient.
>
> Tom