MSVC and DIA

MSVC and DIA

[Gabe Black]

In a couple of other posts I alluded to debugging a target in which I
did not have symbol information.  The target is a custom RTOS running
on an i386 architecture built using different versions of the MSVC
compiler.  I've investigated using Visual Studio to debug the target
and even talked with MS but the amount of work to implement a
"Debugging Engine" to provide this facility is really not worth it.
Furthermore, Microsoft will not allow us to use WinDBG to debug on the
target as well since it isn't a "Windows" target (even though WinDBG
did work for us).

GDB seems like a viable alternative, and all that seems to be missing
is symbol interpretation.  Microsoft provides the Debug Interface
Access SDK (DIA) which I did not find referenced in any of the mailing
lists.  It is an SDK that allows you to get at any of the debug/symbol
information in a PDB even if the format of the PDB changes.  I would
like to add PDB symbol support to GDB.  I am fairly new to GDB but I
have been able to implement the remote stub running on the target
without much trouble.  However the challenge lies in adding the symbol
support.  From what I understand, BFD is where I would need to add the
PDB symbol support.  I didn't find much about it in the gdb online
documentation, both in the user manual and internal documentation.

Does anyone have any pointers or references of documentation/files to
look at to help me get started?  We've tasted the sweetness of using a
source-level debugger and we want more! Am I off my rocker in
attempting this?!

Thanks,
Gabe

Re: MSVC and DIA

[Stan Shebs]

Gabe Black wrote:
> GDB seems like a viable alternative, and all that seems to be missing
> is symbol interpretation.  Microsoft provides the Debug Interface
> Access SDK (DIA) which I did not find referenced in any of the mailing
> lists.  It is an SDK that allows you to get at any of the debug/symbol
> information in a PDB even if the format of the PDB changes.  I would
> like to add PDB symbol support to GDB.  I am fairly new to GDB but I
> have been able to implement the remote stub running on the target
> without much trouble.  However the challenge lies in adding the symbol
> support.  From what I understand, BFD is where I would need to add the
> PDB symbol support.  I didn't find much about it in the gdb online
> documentation, both in the user manual and internal documentation.
>   
Using somebody else's library can be a pain, because you have to adapt 
every mismatched call on the fly, both at the BFD level (which is really 
about symbols and blocks of data), and at the GDB level (which then 
interprets the blocks of data as debug info). You might find it easier 
to simply write a tool that translates a PDB file into an ELF+DWARF 
file, then have GDB read that. Since you control every detail of output, 
you needn't necessarily use BFD to write the file even; just dump out 
canned sequences of bytes for the file as a whole, and similarly for the 
DWARF equivalents of PDB constructs. Running GCC on Linux and doing -S 
-dA (?) will give you annotated assembly code showing what GDB is going 
to expect for different kinds of data, often easier than trying to grok 
the whole DWARF spec.

Stan

Re: MSVC and DIA

[Michael Snyder]

Stan Shebs wrote:
> Gabe Black wrote:
>> GDB seems like a viable alternative, and all that seems to be missing
>> is symbol interpretation.  Microsoft provides the Debug Interface
>> Access SDK (DIA) which I did not find referenced in any of the mailing
>> lists.  It is an SDK that allows you to get at any of the debug/symbol
>> information in a PDB even if the format of the PDB changes.  I would
>> like to add PDB symbol support to GDB.  I am fairly new to GDB but I
>> have been able to implement the remote stub running on the target
>> without much trouble.  However the challenge lies in adding the symbol
>> support.  From what I understand, BFD is where I would need to add the
>> PDB symbol support.  I didn't find much about it in the gdb online
>> documentation, both in the user manual and internal documentation.
>>
> Using somebody else's library can be a pain, because you have to adapt
> every mismatched call on the fly, both at the BFD level (which is really
> about symbols and blocks of data), and at the GDB level (which then
> interprets the blocks of data as debug info). You might find it easier
> to simply write a tool that translates a PDB file into an ELF+DWARF
> file, then have GDB read that. Since you control every detail of output,
> you needn't necessarily use BFD to write the file even; just dump out
> canned sequences of bytes for the file as a whole, and similarly for the
> DWARF equivalents of PDB constructs. Running GCC on Linux and doing -S
> -dA (?) will give you annotated assembly code showing what GDB is going
> to expect for different kinds of data, often easier than trying to grok
> the whole DWARF spec.

I've heard a surprising number if inquiries of this sort recently,
folks wondering how they can use gdb to debug the output of
microsoft compilers.

I'm not getting anything by googling for "pdb to elf",
"pdb to dwarf", or "microsoft to elf".  Anybody think
of any more good search terms?

Re: MSVC and DIA

[Daniel Jacobowitz]

On Fri, Aug 22, 2008 at 01:39:19PM -0700, Michael Snyder wrote:
> I've heard a surprising number if inquiries of this sort recently,
> folks wondering how they can use gdb to debug the output of
> microsoft compilers.
>
> I'm not getting anything by googling for "pdb to elf",
> "pdb to dwarf", or "microsoft to elf".  Anybody think
> of any more good search terms?

There isn't one.  The last time I looked at this I convinced myself
that you need a different library (redistributable, but you need the
headers from a .NET purchased VC++ to use it) to get the right
information; but that may not be true.

What Stan described is pretty much the way I'd do it.  If you're
feeling really fancy it might be possible to do so transparently
to the rest of GDB.

-- 
Daniel Jacobowitz
CodeSourcery