Re: [cdt-debug-dev] CDT Win32 Debugger

[Matthew Ballance <matt.ballance@xxxxxxxxx>]

I agree that dbgeng probably supports more features (I think it's used
as the extension mechanism for windbg?). I just haven't found much
documentation or examples. Have you found something that I missed?

Thanks,
Matthew

On 10/4/05, Mikhail Khodjaiants <mikhailk@xxxxxxx> wrote:

It seems that dbgeng covers much more territory than dgbhelp. Good examples,
are conditional breakpoints and watchpoints and registers.
Basically, as Magnus mentioned, dgbeng is a one-to-one support of the
command-line debugger features.

----- Original Message -----
From: "Matthew Ballance" <matt.ballance@xxxxxxxxx>
To: "cdt-debug-dev" < cdt-debug-dev@xxxxxxxxxxx>
Sent: Monday, October 03, 2005 3:49 PM
Subject: Re: [cdt-debug-dev] CDT Win32 Debugger


> Incidently, one of the more useful sites with info on the dbghelp API
> is: http://www.debuginfo.com <http://www.debuginfo.com>
>
> The Win32 SDK documentation is helpful for detailed information about
> specific functions, but doesn't provide much of a 'big picture'.
>
> -Matthew
>
>
> On 10/3/05, Matthew Ballance < matt.ballance@xxxxxxxxx
> <mailto:matt.ballance@xxxxxxxxx> > wrote:
>
> Mikhail,
>
>    I have read of some differences between older OS-supplied dbghelp
> library versions and the newer version supplied by the Debug tools. From
> my experiments, it seemed that the current release of dbghelp works
> well.
>
>    dbghelp simply provides access to the debug information in PDB
> format. Breakpoints, for example, are set by inserting a breakpoint
> instruction (int 3) in memory.
>
>    My 'big picture' goal for this project is to provide a debugger that
> works with two compiler toolchains that are commonly used on Windows:
> GCC and Visual C++. I use both (depending on what I'm working on) in my
> work and extracurricular activities. I would like to not have to choose
> my debugger based on the compiler I'm currently using (it gets more
> complicated when I'm using a library compiled with one toolchain with an
> app compiled with the other toolchain. Which debugger should I use?). My
> thought is that I can use the dbghelp library to provide access to the
> PDB debugging information and access the dwarf debug info using some
> other API (there are native APIs and - possibly - enough functionality
> in a Java API). This way, I can debug my application regardless of which
> toolchain was used. I doubt that I could do this if I used the dbgeng
> API.  In addition, from my searching on the web, dbghelp has much more
> information and examples that dbgeng.
>
>    I suppose it remains to be seen whether others think a
> 'dual-toolchain' debugger is useful... Feedback on this point is
> especially appreciated.
>
>
> Regards,
> Matthew
>
>
>
>
> On 10/3/05, Mikhail Khodjaiants < mikhailk@xxxxxxx
> <mailto:mikhailk@xxxxxxx>  > wrote:
>
> Matthew,
>
> Please, see my comments inline.
>
> ----- Original Message -----
> From: "Matthew Ballance" <  <mailto:matt.ballance@xxxxxxxxx>
> matt.ballance@xxxxxxxxx>
> To: "Mikhail Khodjaiants" < mikhailk@xxxxxxx <mailto:mikhailk@xxxxxxx> >
> Cc: "CDT Debug developers list" <  <mailto: cdt-debug-dev@xxxxxxxxxxx>
> cdt-debug-dev@xxxxxxxxxxx>
> Sent: Monday, October 03, 2005 11:07 AM
> Subject: Re: [cdt-debug-dev] CDT Win32 Debugger
>
>
>>
>> Hi Mikhail,
>>    Thanks for the feedback on dbghelp. Can you provide any specifics
> on
>> differences you saw between versions?
>
> As I mentioned, it was almost two years ago. I had different Windows
> versions on my machines and it took some time to figure out why it
> didn't
> work.
> Doug has done much more, but as far as I know there are problems with
> such a
> basic task as the breakpoint setting.
>
>>    There are two reasons that I'm reluctant to use dbgeng: It's not
>> redistributable and I think it would be more difficult to support
>> debugging both Visual Studio and GCC-compiled applications (as I
>> understand it, dbgeng contains both symbol-table and debugger
>> functionality. It would, for example, be difficult to insert debug
> info
>> from GCC-compiled objects).
>>
>
> What do you mean by  "insert debug info from GCC-compiled objects"?
>
>>    Since dbghelp is redistributable, would specifying a supported
>> version of dbghelp and shipping that version with binary releases of
> the
>> debugger solve any problems? Can you see problems with this approach
>> (practical or legal)?
>>
>
> I'm definitely not an expert in the legal issues, but in any cases the
> whole
> toolchain has to be installed.
>
>>    I appreciate your input!
>>
>> Regards,
>> Matthew
>>
>>
>> On 10/3/05, Mikhail Khodjaiants < mikhailk@xxxxxxx
> <mailto:mikhailk@xxxxxxx>
>> <mailto: mikhailk@xxxxxxx <mailto: mikhailk@xxxxxxx> > > wrote:
>>
>> Matthew,
>>
>> I played with the Win32 API and DbgHelp library a couple of years ago
>> and I
>> had problems with different versions of DbgHelp. As Doug pointed out
> in
>> one
>> of his postings to this list it is worth to look at DbgEng.dll instead
>> of
>> DbgHelp.
>>
>> Regards,
>> Mikhail Khodjaiants
>>
>> ----- Original Message -----
>> From: "Matthew Ballance" < matt.ballance@xxxxxxxxx
> <mailto:matt.ballance@xxxxxxxxx>
>> <mailto:  <mailto:matt.ballance@xxxxxxxxx> matt.ballance@xxxxxxxxx> >
>> To: "cdt-debug-dev" <  <mailto:cdt-debug-dev@xxxxxxxxxxx>
> cdt-debug-dev@xxxxxxxxxxx
>> <mailto: cdt-debug-dev@xxxxxxxxxxx <mailto:cdt-debug-dev@xxxxxxxxxxx>
>> >
>> Sent: Friday, September 30, 2005 7:39 PM
>> Subject: [cdt-debug-dev] CDT Win32 Debugger
>>
>>
>>> Hi all,
>>>
>>>    I've started work on a CDT win32 debugger using the 'dbghelp'
>>> library supplied by Microsoft. This work builds on the
>>> org.eclipse.cdt.debug.win32.core and org.eclipse.cdt.debug.win32.ui
>>> plugins started by Doug Schaefer (and others?).
>>>
>>>    The primary goal of the project is to support debugging of
>>> applications compiled with the Microsoft compiler. The debug format
>> used
>>> by the Microsoft compiler is proprietary and undocumented. Microsoft
>>> supplies the dbghelp library to provide access to the debug
>> information
>>> emitted by its compiler. The library is freely-distributable, which
> is
>>> important (at least to me): An important requirement of this debugger
>> is
>>> that all components can be distributed with the debugger. The user
>>> should not need to install extra components if at all possible.
>>>
>>>    A secondary goal of the project is to create a debugger that can
>>> debug applications compiled with GCC as well as with the Microsoft
>>> compiler. This goal will be tackled in phase2 of the project (once
> all
>>> features are supported for Microsoft-compiled apps).
>>>
>>>    Thus far, I've mainly been doing research to find good sources of
>>> information about the Sym API (the API supplied by dbghelp.dll). The
>> API
>>> is documented in the Microsoft SDK  documentation, but I've found
> that
>>
>>> some more involved examples to be very helpful. I've also started
>>> prototyping the debugging using what I've learned about walking the
>>> stack, accessing local symbols, settings breakpoints, etc.
>>>
>>>    Since I'm very early in the design and implementation of this
>>> project, I would appreciate any feedback that others have. I'm
>>> particularly interested to know whether others would be interested in
>> a
>>> debugger that can debug applications with M.S.-compiled and/or
>>> GCC-compiled components.
>>>    If others are interested in working on implementation, I would
> also
>>> be interested.
>>>
>>>
>>>
>>> Thanks and Regards,
>>> Matthew
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>