Menu

Main_Page

Anonymous bbar

About tds2dbg

tds2dbg is a tool that converts Borland Turbo Debug Symbol files (tds) to Microsoft DBG symbol files.

Tools for Microsoft Windows like Dr. Watson or the MiniDumpWriteDump function from dbghelp.dll can be used to generate minidumps of an application when an unhandled exception occurs. Dr. Watson will do it automatically, and MiniDumpWriteDump can be combined with Structured/Vectored Exception Handling to do the same thing. Another related to is Google Breakpad.

Minidump files contain a partial snapshot of an applications state and can be loaded into one of the Microsoft Debuggers, e.g. windbg from the Debugging Tools package, for off-line investigation of the problem. To this end, the debugger also needs debugging symbols for the application. Unfortunately, debugging symbols generated by Borland C++ or Delphi (tds files) are not understood by the Microsoft debuggers and Borlands debuggers are unable to handle the minidumps. So, if your application happens to be written in Borland C++ or Delphi, you will need a tool like tds2dbg to convert the Borland debugging symbols into something that can be used by the Microsoft debuggers.

The advantage of relying on the tds files instead of map files from the linker is that far more information can be extracted from the tds files and hence potentially much more useful dbg files generated. Currently, however, the generated dbg files only contain source-file and line number information as well as address information on public and (optionally) static symbols (functions and variables). Debug information on local variables and functions is currently not converted, although that is often needed for effective debugging. Manual decoding of the call stack is required to investigate local variables. However, one can often get surprisingly far with just the debug information already provided by tds2dbg.

How To

tds2dbg program.exe

tds2dbg will read the Borland debug symbol file associated with the Microsoft Windows executable program.exe (program.tds) and create a corresponding Microsoft DBG debug symbol file (program.dbg). Additionally, it will modify a flag in program.exe to signal that debug symbols are available externally to the executable.

The general syntax for invoking tds2dbg is as follows:

tds2dbg [ [-h|--help] | [-t|--types] [-s|--statics] [--] program.exe ]

The listed options are described below:

  -h, --help     Prints a help text. Running tds2dbg without arguments
                 will do the same.
  -v, --verbose  Each occurence of this option increases verbosity.
  -q, --quiet    Operate silently.
  -t, --types    Convert types (incomplete feature).
  -s, --statics  Treat statics as publics.
  -b, --barecv   Write bare code view data. No PE header is added.

The -b option can be used to generate a CodeView file without PE header file as used by the Open Watcom debugger. Note, however, that tds2dbg is currently unable to generate CodeView debug information that will be accepted by the Open Watcom debugger.

Similarly, you can use the the wstrip tool from the Open Watcom tool suite to move the CodeView debug information from an executable generated by the Open Watcom compiler to a separate debug file. If you ensure that this file has the .tds exentension, tds2dbg will be able to generate a corresponding dbg file for you. For some reason, however, such dbg files are not usable by windbg. It seems that windbg has problems with the PE header generated by the Open Watcom compiler.

Interoperability with the Open Watcom compiler is interesting because the Open Watcom suite provides the Dr. Watcom tool. This is a tool similar to Dr. Watson. However, Dr. Watcom generates minidumps in another format than the Microsoft minidumps. Hence, one needs the Open Watcom debugger, as well as debugging symbols acceptable to it, to investigate such dumps.

Maturity

Version 0.2.0 of tds2dbg has received very little testing. Please join in, try it out, and report any issues you find.

Roadmap/Ideas

  1. Convert non-public and non-static symbol names (names of local functions and variables)
  2. Convert types
  3. Align the generated CodeView data with that generated by the Open Watcom compiler.
  4. Generate CodeView NB10 (.pcb files) - requires quite a bit of reverse engineering as this format is undocumented.

See Also

  1. Community portal

MongoDB Logo MongoDB