Doug pointed out that the Debugging Tools help contains info on the
dbgeng API. I've scanned that and it looks decent, anyway...
My plan, for now, is to continue work with just dbghelp due to the
constraints of one potential application of this debugger (embedded in a
commercial application that must debug V.S as well as GCC code and
should not require the user to install any extra components). If it
turns out that the debugger is too limited, then it looks like dbgeng
will be a good alternate solution.
Mikhail, you mention conditional breakpoints, etc... Does CDI have its
own condition language, or assume that the supported condition language
will be that of the slave debugger? (Sorry, haven't gone exploring yet
in this area and thought you'd be able to give me a quick answer)
Thanks and Regards,
Matthew
On 10/4/05, Matthew Ballance < matt.ballance@xxxxxxxxx
<mailto:matt.ballance@xxxxxxxxx> > wrote:
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 < <mailto:mikhailk@xxxxxxx>
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
<mailto:matt.ballance@xxxxxxxxx> >
To: "cdt-debug-dev" < <mailto:cdt-debug-dev@xxxxxxxxxxx>
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> <
<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 < <mailto:matt.ballance@xxxxxxxxx>
matt.ballance@xxxxxxxxx
<mailto: 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>
<mailto: <mailto:mikhailk@xxxxxxx> mikhailk@xxxxxxx> > wrote:
Matthew,
Please, see my comments inline.
----- Original Message -----
From: "Matthew Ballance" < <mailto: matt.ballance@xxxxxxxxx
<mailto:matt.ballance@xxxxxxxxx> >
<mailto:matt.ballance@xxxxxxxxx> matt.ballance@xxxxxxxxx>
To: "Mikhail Khodjaiants" < mikhailk@xxxxxxx <mailto:mikhailk@xxxxxxx>
<mailto: <mailto:mikhailk@xxxxxxx> mikhailk@xxxxxxx> >
Cc: "CDT Debug developers list" < <mailto: cdt-debug-dev@xxxxxxxxxxx
<mailto:cdt-debug-dev@xxxxxxxxxxx> >
<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: <mailto:mikhailk@xxxxxxx> mikhailk@xxxxxxx>
<mailto: 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" < <mailto:matt.ballance@xxxxxxxxx>
matt.ballance@xxxxxxxxx
<mailto: matt.ballance@xxxxxxxxx <mailto:matt.ballance@xxxxxxxxx> >
<mailto: <mailto: <mailto:matt.ballance@xxxxxxxxx>
matt.ballance@xxxxxxxxx> <mailto:matt.ballance@xxxxxxxxx>
matt.ballance@xxxxxxxxx> >
To: "cdt-debug-dev" < <mailto: cdt-debug-dev@xxxxxxxxxxx
<mailto:cdt-debug-dev@xxxxxxxxxxx> >
<mailto:cdt-debug-dev@xxxxxxxxxxx> cdt-debug-dev@xxxxxxxxxxx
<mailto: cdt-debug-dev@xxxxxxxxxxx <mailto:cdt-debug-dev@xxxxxxxxxxx>
<mailto: <mailto:cdt-debug-dev@xxxxxxxxxxx> 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
