diff mbox

symfile debug file additional search in sysroot

Message ID CAFMZ0FnoHH82DkpjNRjFt24M9i_qO_s2sR25Y8e7s_6PA047Dw@mail.gmail.com
State New, archived
Headers

Commit Message

Cédric Buissart June 10, 2015, 7:44 a.m. UTC 
  Hi all,

This patch allows coredump analysis taken from foreign machines in an
easy way using the sysroot option. e.g. :
- extract the necessary binaries and debuginfo in
/coredump/<coredump-ID>/ (e.g. : via rpm2cpio if RPM is used)
- in gdb, set sysroot to /coredump/<coredump-ID>/
- and your good to go : the sym files will also be searched relative
to /coredump/<coredump-ID>/

In practice, you'll still also want to add that folder to your
auto-load safe-path, and another patch will be required for source
access (e.g. : the list command), but I have found this patch very
useful in my daily work and to set up scripts to automatically build a
coredump analysis environment

Basically, when searching for a separate debug file, if it is not
found, the patch kicks in and set an additional search in
<sysroot>/<debugdir>.

Benefits :
 - no need for recreating a full OS or a container to open a coredump.
 - you can use a modern GDB, with your own plugins and scripts, to
diagnose a coredump created on an old OS
 - you can export the recreated OS sample and let other people mount
and use their own gdb to look at the coredump.

There is no drawback : old style search will still be fully functional.

I am unsure this was sufficiently clearly explained, but I hope I will
trigger your interest.

:) If you have a better way of easy opening coredump without building
a whole OS/container and without that patch, please let me know

Cedric

Comments

Gary Benson June 10, 2015, 3:10 p.m. UTC | #1 
Hi Cédric,

Cédric Buissart wrote:
> This patch allows coredump analysis taken from foreign machines in an
> easy way using the sysroot option.
...
> Basically, when searching for a separate debug file, if it is not
> found, the patch kicks in and set an additional search in
> <sysroot>/<debugdir>.
> 
> Benefits :
>  - no need for recreating a full OS or a container to open a coredump.
>  - you can use a modern GDB, with your own plugins and scripts, to
>    diagnose a coredump created on an old OS
>  - you can export the recreated OS sample and let other people mount
>    and use their own gdb to look at the coredump.
> 
> There is no drawback : old style search will still be fully functional.
> 
> I am unsure this was sufficiently clearly explained, but I hope I will
> trigger your interest.

I'm going to take a look at your patch, it crosses into some work I've
been doing to allow GDB to fetch debuginfo from containers and remote
targets.

I may not do it straight away, but I wanted you to know your patch
isn't being ignored.

Thanks,
Gary
diff mbox

Patch

diff --git a/gdb/symfile.c b/gdb/symfile.c
index 84858dc..0f68885 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1533,6 +1533,18 @@  find_separate_debug_file (const char *dir,
              do_cleanups (back_to);
              return debugfile;
            }
+
+          /* or we can try to inject debugdir between sysroot and
normal path */
+          strcpy (debugfile, gdb_sysroot);
+          strcat (debugfile, debugdir);
+          strcat (debugfile, canon_dir + strlen (gdb_sysroot));
+          strcat (debugfile, "/");
+          strcat (debugfile, debuglink);
+          if (separate_debug_file_exists (debugfile, crc32, objfile))
+            {
+              do_cleanups (back_to);
+              return debugfile;
+            }
        }
     }