2

I am trying to create a way to transfer the debug information of a C++ project to a remote location for testing. In the current development cycle, small changes to the code require the entire binary (100s MB in size and mostly debug info) to be transferred.

Currently my approach to addressing this is by splitting the debugging information from the object files (the size of which without the debugging info is manageable on my connection) using -gsplit-dwarf and then diffing the debug files against a copy of the build currently on the remote box.

The aim is to have a set of patches for the debug files of a project so that new code can be debugged at a remote location. The connection between the remote location and the local machine is slow and so minimization of the size of the patches is paramount but it should also be balanced with the run time of the tool. I have looked into bsdiff and xdelta as potential solutions and have run into a conundrum where xdetla is fast but too large and bsdiff is perfect in terms of size but the run time and memory requirements are a little higher than I would like it to be.

Is there a tool or approach I am missing or am I just going about this the wrong way? Some alternative to bsdiff and xdelta perhaps? I know that a tool like gbdserver won't work in this situation because of some of the requirements we have with the actual debugging. Could some alteration of bsdiff help the performance? And indeed if the approach I'm using is sound, what would be a good way to keep a copy of the build on the remote machine around to diff against.

narendasan
  • 23
  • 3
  • There is some way to get the debug info in a different file than the executable, but I don't know how to do that. – Basile Starynkevitch Jul 29 '14 at 19:37
  • Yeah, I use the -gsplit-dwarf flag when compiling with C++ which separates the debug info into .dwo files. The issue I have is that the .dwo files are too large to transfer in a timely manner. What I am trying is using bsdiff to generate patches those files. Sorry if that was not clear. – narendasan Jul 29 '14 at 20:59
  • 1
    with gdbserver I guess that you could keep the debug info locally, and only transfer remotely the executable. – Basile Starynkevitch Jul 29 '14 at 22:10
  • We use the debug symbols to generate backtraces for exceptions in the running application. So I believe they need to be on the test machine. – narendasan Jul 30 '14 at 15:08

1 Answers1

0

The simplest way is to use "strip" to copy the debuginfo into a separate ".debug" file, and then use "strip" again to remove the debug info from the executable that you will deploy. The "strip" manual explains how to do this, look for the "--only-keep-debug" option.

After you do this, you can tell gdb about the separate debug info in various ways. The very best way is to use the "build-id" feature. This is what modern Linux distros do. However there are other ways as well. There's a whole section in the gdb manual about separate debug files.

The key point here is that you can start gdb on the stripped executable and it will find the separate debug info automatically. This data can all be local, so you won't need to deploy the debug info.

If you still care about shrinking debug info even when this is done, you can look at the "dwz" tool. This is a DWARF compressor. However this usually only matters if you plan to ship the debug info somewhere -- distros use it to make it easier to download debug info, but ordinary users won't really see the need.

Tom Tromey
  • 18,974
  • 1
  • 37
  • 55
  • This build-id feature sounds like it could help, how does it work? – narendasan Jul 31 '14 at 21:46
  • There are docs in the gdb (and maybe gcc?) manuals. Basically it puts a hash code into the resulting executable or library, and then this hash is used to find the corresponding debuginfo -- strip preserves the hash when separating the code from the debuginfo. – Tom Tromey Aug 01 '14 at 02:17
  • The build id and related features really helped, it allowed me to make both the executable and dwarf files portable. Thanks! – narendasan Aug 12 '14 at 18:12