Thanks so much, folks, for writing back. I did get the problem solved. I hadn't changed the nmake.opt file to generate the debug database. (One was being output for some reason, but it was incomplete. For the archives, I documented this more fully a few e-mails back.)
Thanks again! On Sun, Dec 21, 2008 at 12:16 AM, Martin Chapman <[email protected]> wrote: > Joel, > > I debug into gdal source from visual studio all the time. Here is what I > do: > > 1. Use nmake to build gdal from the command line with the nmake.opt file set > to build gdal in the debug configuration. > 2. Copy the gdalxxx.dll, gdalxxx_i.lib and gdalxxx.pdb to the same directory > as my application exe or dll. > 3. Run my application in debug mode with a break point in my code on the > line I want to debug. > 4. When the code breaks in my code then I press F11 to step into the gdal > code. > > If it doesn't work then something is out of sync between your code and the > gdal files your are linked against. Most likely your code can't find the > gdal pdb or the files are out of date. Make sure you do a full rebuild on > both projects so all files are up to date with the debug symbols. Sometimes > I make that mistake and my code won't step into gdal so I do a full rebuild > and then it works. > > Martin > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Joel Odom > Sent: Friday, December 19, 2008 12:36 PM > To: [email protected] > Subject: Re: [gdal-dev] Debugging on Windows Using Visual Studio > > Problem solved. For the benefit of the group and the searchable list > archives, I'll describe here what was going on. > > My build on Windows, using makegdal80.sln, was generating a gdal15.dll > with symbols and gdal15.pdb file. For whatever reason, these files > did not contain sufficient information for me to step in to the code > in a debug session. After poking around for some time, I found that > the OPTFLAGS in nmake.opt were set to the optimized build. I'm not > sure why I was seeing the debug symbols loading, but changing OPTFLAGS > to generate a gdal.pdb (along with the gdal15.pdb) gave me the debug > information I needed. (In 1.6.0, the OPTFLAGS is set for debug when > DEBUG is defined, which seems to make more sense.) > > > > On Fri, Dec 19, 2008 at 11:22 AM, Joel Odom <[email protected]> wrote: >> More notes on the issue below. >> >> >> ---------- Forwarded message ---------- >> From: Joel Odom <[email protected]> >> Date: Fri, Dec 19, 2008 at 11:21 AM >> Subject: Re: [gdal-dev] Debugging on Windows Using Visual Studio >> To: Frank Warmerdam <[email protected]> >> >> >> I'm building from makegdal80.sln. I'm also starting my debug sessions >> from this same solution. I'm getting symbols in gdal15.dll and the >> .pdb file, but I still can't set a break point anywhere. It's like >> the debug symbols don't map correctly to the source code. >> >> I'm wondering if there is some flag in the makefile options that is >> not being set, so the program debug information is incomplete? I am >> able to set a break point in my dll that calls gdal, but not anywhere >> in the gdal methods. Again, this is all in VS 2005. I'll post an >> answer here if I figure out the problem before I give up, but if >> anyone has any ideas, I'd appreciate it. >> >> >> >> On Fri, Dec 19, 2008 at 11:10 AM, Frank Warmerdam <[email protected]> > wrote: >>> Joel Odom wrote: >>>> >>>> Bruce. I'm trying to debug an app that uses GDAL from unmanaged C++ >>>> on Visual Studio 2005. I've tried for an hour or two to step into >>>> gdal, running debug sessions both from the project file from which I >>>> build gdal and from the app that calls into GDAL, but even when I run >>>> from the gdal solution itself, it still doesn't let me step through >>>> source code, even though the modules window says gdal15.dll is loaded >>>> with symbols from the same location as my .pdb file. >>> >>> Joel, >>> >>> I have generally not had problems with this. Did you build GDAL using >>> the nmake files or the solution? I've had good luck debugging the >>> utilities and into GDAL itself with visual studio. I normally run things >>> from the commandline and pop into visual studio when things crash (even >>> triggering crashes at select points). >>> >>> This is usually with visual studio 2003. >>> >>> Best regards, >>> -- >>> > ---------------------------------------+------------------------------------ > -- >>> I set the clouds in motion - turn up | Frank Warmerdam, >>> [email protected] >>> light and sound - activate the windows | http://pobox.com/~warmerdam >>> and watch the world go round - Rush | Geospatial Programmer for Rent >>> >>> >> >> >> >> -- >> http://giscoder.blogspot.com/ >> >> >> >> -- >> http://giscoder.blogspot.com/ >> > > > > -- > http://giscoder.blogspot.com/ > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://giscoder.blogspot.com/ _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
